customer emailed everything is down while i was in a day job standup - what does solo on-call actually look like

The connection limit detail matters more than the on-call process. That failure class is entirely preventable and it is the most common way small apps fall over.

Put a connection pooler in front of the database, cap the pool below the server limit, set a sane statement timeout so one bad query cannot hold connections open indefinitely, and add a health endpoint that acquires and releases a connection so your monitor is actually testing the thing that broke.

Spending an evening on that buys you more sleep than any alerting configuration, because the incident does not happen.

Separate the three problems, because you are trying to solve them with one mechanism and they have different answers.

Detection: an external uptime check hitting a real endpoint that touches the database, not a static page, every minute, alerting to your phone with a distinct sound that gets through your focus mode. This is cheap or free and it turns eighty-five minutes of ignorance into two.

Communication: a status page and an autoresponder. If the check fires it should post automatically. A customer who sees an acknowledged incident behaves completely differently from a customer shouting into a void.

Response: this is the one you cannot fully solve, and that is fine. Being unable to respond for two hours is acceptable if detection and communication are instant. What is not acceptable is finding out from a customer.

Say it out loud on the pricing page. Mine reads: support is answered within one working day, and there is no guaranteed response time outside UK business hours. It has cost me exactly one deal, from a company that would have been miserable to have as a customer.

Everything gets easier once the expectation is written down. You stop feeling guilty for being in a meeting, and customers stop guessing.

Also worth being realistic about what customers actually expect from a tool at this price. Ninety minutes on a Tuesday with an honest email afterwards is survivable for almost every product that is not payments or auth. People forgive downtime. They do not forgive silence, and they really do not forgive discovering it themselves twice.

Degrade rather than die. If the database is unreachable, serve a cached read-only view with a banner instead of a 500. Most of my users on any given hour are looking at things, not changing them, and a read-only app looks like a minor blip while an error page looks like a company that has gone out of business.

One thing that cost me nothing: a five line runbook in a note on my phone. What to check first, the command to restart the worker, the URL of the hosting dashboard, and the login. Twelve minutes of fixing while standing in a corridor is achievable. Twelve minutes of remembering how the system works while standing in a corridor is not.