Guides for on-call assume a team. Plenty of products are kept alive by one person. Pretending you have a weekly rotation with yourself is how you burn out and then miss the real outage.
What solo on-call can mean
You are the primary. Always. The goal is not fairness between engineers — there are no other engineers. The goal is survivable nights and a product that still gets fixed when it breaks.
That means fewer pages, clearer pages, and a written plan for when you are on a plane.
Ruthless sorting
With one human, page vs notify is not a nice-to-have. It is the product.
- Night pages: only full customer blockers you can confirm.
- Daytime: everything else.
- Never: staging, vanity metrics, single-probe flakes.
Invest in confirmation so a path blip does not own your sleep. Consensus-style checks exist for this shape of life.
Build a tiny safety net anyway
Even solo founders can have:
- A secondary human with access — co-founder, spouse who knows the host login, contractor on retainer for emergencies. They do not need to be full-time. They need a path into the systems and a runbook.
- Vacation mode — paid status page note, paused non-critical monitors, or a friend watching Slack for three days.
- Vendor dependencies documented — when AWS is on fire, you should not discover the account owner email at 4am.
Hours of coverage
Be honest with customers. "Best effort outside US business hours" in an early SLA beats an implied 24/7 you cannot staff. Enterprise buyers will push; that is the moment you hire or buy a backup, not the moment you lie on a marketing page.
Tools
You still want schedules, ack, and escalation — even if level 2 is a person outside the company. Tallwatch includes those on the free plan because side projects that take money deserve a real pager path. The tool will not create a second you. It will only make the one you more deliberate.
Solo on-call is a season. Design it so you still want to build the product in the morning.