Why coverage fails when it is bought as a pager
Plenty of teams reach the point where a founder or one senior engineer is the permanent on-call, because nobody else knows enough to take a shift. The usual reaction is to hire outside help to “just answer the phone”. That rarely works. A person who receives an alert for a system they have never seen can acknowledge it, but cannot do much more.
Effective round-the-clock coverage is the visible end of a longer chain: good alerts, good runbooks, clear authority and sound access. This is why we deliver it inside a Managed DevOps engagement and not as a standalone product. The foundations come first, and our SRE and incident response service builds them.
What good coverage looks like
Judge a coverage arrangement against concrete criteria rather than a promise of “24/7”.
- Alerts are worth waking for. Each paging alert reflects user impact or imminent risk and links to a runbook.
- Authority is explicit. The on-call engineer knows which actions they may take alone and which need your approval.
- Escalation is real. There is a named person on your side for product and business decisions, reachable at night, with a backup.
- Communication is calm and consistent. Updates follow a template and a cadence, so stakeholders are not left guessing.
- Learning is built in. Every out-of-hours page ends up in a review that asks how to prevent the next one.
How it works in practice
Readiness before go-live
We do not start the pager on day one. First comes a readiness review: which alerts can page, do they have runbooks, are they routed correctly, and does the person receiving them have the access needed to act? Gaps are closed or the alert is demoted to a ticket. Teams often discover at this stage that the rota they had was held together by one engineer’s memory.
Scope and authority
We write down an action matrix. A simple version looks like this:
| Situation | We act alone | We ask first | We escalate to you |
|---|---|---|---|
| Bad deploy causing errors | Roll back to last good version | Rolling back a release with a data migration | Decision on feature removal |
| Capacity saturation | Scale within agreed limits | Raise limits or spend | Architecture change |
| Dependency outage | Switch to documented fallback | Failover to another region | Customer communication wording |
| Security alert | Contain using the playbook | Isolate production systems | Disclosure and legal questions |
The exact boundaries are yours to set. The point is that nobody at 3am has to guess.
Tools and access
Alerts flow from Prometheus and Alertmanager into a paging tool such as PagerDuty, Opsgenie or Grafana OnCall, then into an incident channel. Access is by named individual account with least privilege, and a break-glass route for emergencies is logged and reviewed. We describe the paging side in detail in our guide to setting up an on-call rotation.
Running an incident with our engineer on shift
- The alert pages our on-call engineer, who acknowledges it and opens the runbook.
- They declare the incident in the shared channel with a severity, following your severity matrix.
- They take in-scope actions and record each one with a timestamp.
- If the issue exceeds scope, the escalation policy pages your named contact with a short summary: impact, what was tried, what is suspected.
- After recovery, a short handover note lands in your channel before your team starts its day.
The aim is that your people wake up to a clear account of what happened, not a mystery.
Decisions and trade-offs
Full outsourcing versus a hybrid. Handing first-line coverage over entirely frees your engineers, but you lose some immediacy for application bugs. A hybrid, with us on infrastructure and platform alerts and your developers on code-level ones, keeps knowledge in-house.
Follow-the-sun versus single region. If your team spans time zones, internal rotations can follow the sun. If it does not, outside coverage removes the need to wake anybody for routine events.
Cost versus risk appetite. Round-the-clock cover costs more than business-hours support. For an internal tool or early prototype where overnight downtime is acceptable, it is not worth it. We would say so rather than sell it.
When you should not buy this. If your alerts are mostly noise or you have no runbooks, fix those first. Putting a rotation in front of a noisy system only makes the noise more expensive.
The morning-after handover
Coverage is judged as much by the morning as by the night. Each overnight incident ends with a short written note in your channel: what fired, what was affected, what we did, what is still open and what we recommend. Anything needing a decision is flagged at the top, so the first engineer in can act on it within minutes. Non-urgent follow-ups become tickets with a clear owner instead of lingering in chat, which is how the same page ends up repeating next week.
Common failure modes
- Coverage starts before runbooks exist, so every page becomes an escalation.
- Nobody on the client side is reachable at night, which turns an escalation into a dead end.
- Authority is vague, so the engineer waits for permission while customers wait for a fix.
- Pages are handled but never reviewed, so the same cause wakes someone every week.
- Access is shared or over-broad, creating a security problem alongside the operational one.
Delivery and handover
You receive the escalation policy, the action matrix, the access model, the runbook library and a regular review of pages and their causes. Coverage ends or changes by agreement, and everything operational (schedules, runbooks, tooling configuration) lives in systems you own, so you are never locked in. Our engagement models page explains how Managed DevOps is scoped.
How to tell it is working
Track pages per week and the share handled without escalation, time from page to first correct action, repeat pages for the same cause, and how many of your own engineers were woken at all. The best sign is a falling trend in night-time pages over several months, because it means the reviews are removing causes. To see whether this fits your stack, book a consultation.