Setting Up On-Call for a Small Startup Without Burning Everyone Out

Every startup eventually needs on-call. The first paying customer expects the product to work at 2am. The first enterprise buyer asks about incident response in the security questionnaire. And somewhere in between, someone gets paged for the first time and realizes nobody planned for this.

Setting up an on-call rotation for a small team is different from what any operations manual describes. The manuals assume a rotation of ten engineers. You have three. Below is what actually works.

Why small-team on-call is harder

A rotation of ten engineers gives each person a week of on-call every two and a half months. That's manageable. A rotation of three engineers means every third week for the rest of the year. That's exhausting.

The temptation is to not have a rotation at all. "We'll all watch alerts." That works for a couple of months and then breaks — usually because two engineers assume the other saw the page, and the customer sees a 90-minute outage.

The real work of small-team on-call isn't the schedule. It's making sure a page happens rarely enough that a small team can absorb it.

Setting up the rotation

The mechanics come first. Later we'll cover how to make on-call bearable.

Weekly rotations

Daily rotations sound humane but destroy focus. You spend the day mentally on-call, ship nothing, and forget the context the next day. Weekly is the standard for a reason.

Sunday-to-Sunday works better than Monday-to-Monday because handoffs happen when the on-call person is fresh, not on Monday morning when everyone's overwhelmed.

A real handoff

Fifteen minutes at the start of each week. The outgoing on-call reports what happened, what's still open, and what to watch for. Skip this and each rotation starts blind.

Escalation paths

Even with a primary on-call, you need a secondary who can be woken up if the primary doesn't respond within 15 minutes. On a three-person team, that's the two people who aren't primary. A written escalation policy in your paging tool handles the mechanics automatically.

Follow-the-sun if you can

If your team spans time zones — even just US East and Europe — split the rotation by time zone. The person in London handles overnight for US customers; the person in New York handles daytime. Nobody gets paged in the middle of their sleep. This is a huge quality-of-life win when the team supports it.

The tooling that pays for itself

Two paid tools are worth it early. Everything else can wait.

A pager service

PagerDuty is the default. Incident.io, Grafana OnCall, or Better Stack are cheaper alternatives that work fine for a small team. They handle escalation, scheduling, notifications, and phone calls when SMS doesn't wake you.

What you get for the $20-40 per user per month: someone gets paged reliably, escalates automatically, and everything is logged. Trying to build this with Slack alerts and calendar invites is a false economy.

A monitoring service that pages intelligently

Datadog, Grafana, New Relic, or a similar tool that lets you set alert thresholds and route pages appropriately. The critical distinction: alerts and pages are different.

Alerts go to a channel where someone will look at them within business hours. Pages wake a human up. Every alert you turn into a page trains the team to ignore the pager. Keep pages rare and specific.

What deserves a page and what doesn't

The single biggest driver of on-call burnout is bad paging discipline.

Page-worthy

• The product is down for real users.
• Payments are failing.
• Data is being lost or corrupted.
• Security incident in progress.

Not page-worthy at 3am

• CPU is at 80%.
• One API call took 8 seconds instead of 2.
• A single user reported a bug.
• A cron job that runs weekly is a bit slow.

The rule: if the on-call engineer can't do anything about it at 3am, don't page them at 3am. Push it to a business-hours channel. Fix it in the morning.

Compensating on-call fairly

Being on-call is a real cost, and pretending it isn't is how you lose engineers. Every startup we've worked with that ran on-call well compensated it explicitly.

Options range in size. Extra pay per week of on-call is common — a few hundred dollars flat, more if incidents happened. A day off after a rough week works well. Cash bonus for each paged incident that woke someone up.

The specifics matter less than the acknowledgment. "You gave up your evenings; here's something in return." Engineers who feel their on-call is unpaid work leave.

Reducing the number of pages

The real work of on-call is making it quiet. Every fixed page is a night's sleep for the future team.

Post-mortem every page

Not for blame. To answer: could this page have been avoided? Should this even have been a page? Almost every page tells you something about your alert rules, your product, or your architecture.

Reduce alert noise ruthlessly

The first time a page fires and turns out to be false, tune the threshold. The second time it fires and nobody needs to do anything, delete the page entirely. Alerts that fire more than they matter train the team to ignore the pager.

Kill switches for common failures

If a specific external service — a payment provider, a model provider — is a common cause of pages, wire in a kill switch that lets you route around it during an outage without a redeploy. Our post on feature flags covers the pattern.

What the first month of real on-call feels like

The first month, expect a lot of pages that shouldn't have been pages. Your alert rules were tuned for peace of mind, not real signal. You'll get woken up for things that don't matter.

Fix them as they happen. By month three, pages drop to a few per rotation. By month six, most rotations pass without any pages at all. That's the goal.

If it's not trending that way, the problem isn't the schedule. The problem is upstream — alert quality, product reliability, or infrastructure fragility.

Trade-offs to expect

On-call trades one kind of pain for another. Without a rotation, incidents drag on because nobody's watching. With a rotation, someone loses focus and sleep every week.

The right trade depends on what you're selling. A B2B tool with an SLA needs on-call from the moment you sign the first enterprise deal. A pre-revenue consumer product can wait longer.

The wrong trade is pretending you don't need on-call after you've already promised customers you're reliable. That's how goodwill dies.

Common misconceptions

"We're too small for on-call." You're too small to run on-call badly. Even a two-person rotation with weekly handoffs beats hoping the right person happens to see the alert.

"Cloud services handle everything, so we don't need on-call." Cloud services handle infrastructure. Your app can still go down, your integrations can still fail, and your customers still expect a response.

"On-call is only for engineering." Customer support benefits from a similar rotation — someone owns the front line during any given week. This spreads context, avoids single-person burnout, and improves response quality.

Frequently asked questions

Final note

On-call isn't a badge of maturity. It's a specific kind of overhead you take on because your customers depend on you. Done well, it's boring — the pager rarely fires, and the team sleeps. Done poorly, it's the fastest way to burn out the people you can least afford to lose.

If you're setting up on-call for the first time and want a review of the rotation, tooling, and alert rules, book a call. We've helped teams the size of yours get this right the first time.