On-Call When You're a Team of One: What Actually Matters for Solo Founders
A solo founder can't build on-call around rotation or escalation — there's no second person to hand off to or escalate to. What matters is delivery reliability: a repeating alert that behaves like an alarm, plus a second channel, like SMS or a call, that kicks in automatically if the first goes unacknowledged.
The real problem isn't routing
Most on-call tooling is built to answer "who should this page go to." That question is a central concern of team-based on-call practice — Google's own SRE book devotes an entire chapter to routing and rotation design. For a team of one, that question has exactly one answer, every time, and it's not interesting. The actual problem is narrower and more concrete: will the alert reliably reach the one person who can act on it. That matters most at 3am, when a phone is on silent, face-down, or nearly dead — exactly the conditions under which most alerting setups quietly fail. Sophisticated routing logic solves a problem a solo founder doesn't have; reliable delivery solves the one they do.
Consider what actually goes wrong for a solo operator running their own infrastructure. A database backup job can silently stop running for two weeks before anyone notices, or a payment webhook can start failing at 1am on a Tuesday, and the only person who would know is asleep with a phone face-down on the nightstand. A solo founder has no teammate in a different timezone who happens to be awake and catches the failure in the meantime — the way a distributed team sometimes gets lucky. For a one-person operation, the alert either gets through on the first attempt within the first few minutes, or it doesn't get through until morning, whenever that person wakes up and checks a phone; there is no in-between state where "someone else saw it and is already handling it." That gap is the entire reason delivery reliability matters more than routing logic for a team of exactly one.
What actually matters at this scale
Two things are worth getting right, and neither of them is complicated:
A repeating alert, not a single notification. One push notification is easy to sleep through — a phone briefly lighting up and going quiet again asks nothing of a sleeping brain. An alert that repeats every couple of minutes until it's acknowledged behaves more like an alarm clock. That's exactly the right model when there's no backup person for it to fall through to. If it's not acknowledged, the only fallback is that it keeps trying, louder and more often, until it succeeds.
A second channel in case the first one fails. Push notifications can get killed by the OS. They can get missed because Do Not Disturb or a muted notification channel was left on from the day before. Or they simply don't arrive because of a flaky connection. A secondary channel like SMS, sent automatically if the primary alert goes unacknowledged for a couple of minutes, covers a specific failure mode: a single-channel setup going completely silent for reasons that have nothing to do with whether the founder is actually reachable.
What happens when the founder is traveling?
It still works, as long as the second channel doesn't depend on the same conditions as the first. A founder on a red-eye flight or in an area with spotty signal is exactly the scenario a single-channel setup fails hardest in. Push notifications need a live data connection, and international roaming or airplane mode kills that instantly. SMS degrades more gracefully in patchy coverage.
A voice call, while the most disruptive option, is worth having configured as a last resort for the weekend or travel case, even if it never gets used on a normal week. The point isn't to predict every scenario in advance. It's to have a second channel that fails independently of the first, so one bad connection doesn't take down the only path an alert has.
What's safe to skip for now
Escalation policies, on-call schedules, and groups all solve real problems — for a team with more than one person on the rotation. Setting any of them up for a team of one is pure overhead. There's no second person to escalate to, no schedule to rotate through, no group beyond "me." It's tempting to configure all of it anyway, because it feels like doing things properly.
But the actual leverage for a solo founder is entirely in delivery reliability, not in routing sophistication that has nowhere to route to yet. That's worth revisiting the day a second person joins — not before. Building out a three-step escalation policy for an audience of one just adds screens to click through during an actual incident, with no corresponding benefit.
Where this fits
This is a case where PingParrot's default behavior already matches the actual need. Pages repeat automatically until acknowledged. Delivery isn't locked to a single channel, and the free tier includes three pagers with no feature gating. Escalation and the API are there if they become useful later, but nothing needs to be configured just to get a reliable, repeating alert working today. For a team of one, the tool should stay out of the way until it's actually needed for more than that.