How do you run an on-call rotation when your whole team is three people?

Accept that the rotation is the easy part

With three people the schedule almost writes itself: one week on, two weeks off, or one primary and one backup rotating every week. The hard part is not the calendar. It is that every alert lands on someone who also has a full plate of product work the next morning, and there is no separate operations team to absorb the noise. A rotation that would be fine at a large company becomes unbearable if it fires twice a night, because the same three people are absorbing every single page.

So the first decision is not who is on call, but what is allowed to page at all. The rule that works: only alerts that require a human to act within the hour are allowed to make a phone ring. Everything else goes to a channel that is read in the morning. If you cannot name the action a person would take when woken up by an alert, that alert should not wake anyone. Applying this rule honestly usually cuts the paging list to a handful of checks: the main app, the API, the login flow, and payments. Related: How to Set Up Alerting That Avoids False Alarms

Keep reading: How to Choose an Uptime Check Interval That Actually Catches Outages, Status Page Best Practices That Reduce Support Tickets, Uptime vs Response Time: What to Monitor and Why Both Matter. See how PingCrumb helps you uptime monitoring and hosted status pages.

Design the rotation around recovery, not coverage

A weekly primary works well because it gives the person on call a predictable block and gives everyone else a predictable stretch of uninterrupted sleep. Handovers should happen at a fixed time on a weekday morning, not on Friday evening, so the outgoing person can explain anything odd from the week while everyone is awake. Keep a backup who is paged only if the primary does not acknowledge within a set number of minutes. With three people, the backup is simply whoever was on call last week, because they still have context.

Protect the person coming off a bad night. If someone was up for two hours at 3 a.m., they get a late start and the other two cover the morning. Write this down as policy rather than leaving it to guilt and heroics. Also decide in advance what happens during vacations and illness. With three people, a single vacation turns the rotation into two, which means one week on, one week off. That is sustainable for a couple of weeks and corrosive beyond that, so plan quiet-period releases and avoid risky deploys when the team is short.

Make alerts do the diagnostic work in advance

A page at 2 a.m. that says only that the site is down forces a sleepy person to start from zero. A page that says the API returned a 502 from all three probe locations for four minutes, with a link to the runbook and to the last deploy, gets them to a decision in seconds. Spend time making the alert message useful: which check, which locations, how long, what changed recently. Attach a short runbook per paging alert with the first three things to try. Most incidents on a small app are one of a few repeat causes, and a runbook captures that memory. Related: When should a small SaaS start monitoring DNS resolution separately from HTTP checks?

Use confirmation from multiple locations and a short grace period so that a single failed request never pages anyone. Set a separate, lower-severity channel for slow responses, expiring certificates, and non-critical services. When a page does fire for something that turned out not to need action, treat it as a bug in the alerting and fix it the next day. The rotation only stays livable if the number of nighttime pages trends toward zero, and that only happens if false pages are treated as defects rather than as the cost of doing business. Related: How many monitoring locations do you actually need to confirm a real outage?

Ground rules that keep three people from burning out

Agree on response expectations: acknowledge within a few minutes, post a first status page update within a short window even if you know nothing yet, and escalate to the backup without embarrassment if you are stuck. Agree that no one deploys on a Friday afternoon or right before their own on-call week ends. Agree that a bad week on call earns lighter product work the following week. None of these are technical, and all of them matter more than any tool. Related: Status Page Best Practices That Reduce Support Tickets

Finally, review the pager log together every couple of weeks. Count how many pages fired, how many were actionable, and what the median time to resolve was. Three people can do this in fifteen minutes. If the actionable share is low, tighten the alert rules. If time to resolve is high, improve the runbooks. This loop is what separates a small team with a calm pager from one where on-call becomes a reason people leave. The tools help, but the habit is the thing.