The most effective way to reduce on-call burden is not adding people to the rotation. It is reducing the amount of work each incident creates. Most on-call time goes to investigation, not resolution. Automate the investigation step, and on-call stops being a constant interruption and becomes a manageable part of the job.
Why on-call breaks down on small teams
On a team of 20 engineers with a weekly rotation, each person is on call roughly 2.5 weeks per year. That is manageable. On a team of 5, each person is on call 10 weeks per year, nearly a quarter of their working time. And during those weeks, they are expected to keep building features while also being the first responder for production.
Small teams feel this disproportionately. Every engineer is critical to shipping velocity. When one person is distracted by on-call duties, the entire team slows down. There is no bench. There is no dedicated SRE team to absorb the load.
The standard playbook, "build it, run it", assumes engineers can context-switch between building and firefighting without significant productivity loss. In practice, the cognitive cost of staying alert for pages while trying to write code makes both jobs worse.
Why hiring does not fix on-call
The intuitive solution is to hire more engineers to expand the rotation. But this creates new problems:
- More engineers means more services, which means more alerts. Growth adds complexity. A team that doubles in size typically more than doubles their service count, which increases alert volume.
- New hires need ramp-up time for on-call. It takes months before a new engineer can effectively troubleshoot production systems they did not build. During that time, the existing team carries the same load.
- The cost does not justify the outcome. Hiring an engineer at $150-200K fully loaded to reduce on-call frequency from every 5 weeks to every 6 weeks is not a good use of resources.
On-call burden is not a headcount problem. It is a workload-per-incident problem. Each incident, regardless of team size, requires the same investigation work: pull logs, check deployments, determine impact, decide on action. Making the rotation less frequent does not make each incident less work.
Where on-call time actually goes
When you break down what an on-call engineer actually does during an incident, the time splits roughly like this:
| Activity | Time spent | Can be automated? |
|---|---|---|
| Acknowledging and reading the alert | 2-5 min | Yes |
| Pulling up logs and metrics | 5-10 min | Yes |
| Checking recent deployments | 3-5 min | Yes |
| Determining user impact | 5-15 min | Yes |
| Identifying root cause | 10-30 min | Partially |
| Deciding on action | 5-10 min | No (needs human judgment) |
| Implementing the fix | 15-60 min | Sometimes |
| Documenting what happened | 10-15 min | Yes |
The investigation phase, from alert to "I understand what is happening", takes 25 to 65 minutes and is almost entirely automatable. The decision and fix phases are where human judgment matters. But today, engineers spend more time investigating than deciding or fixing.
Five approaches that actually reduce on-call burden
1. Reduce alert noise
Consolidate duplicate alerts. Add hysteresis so transient spikes do not page. Group related alerts so one incident does not trigger five notifications. This is table stakes, not a solution. It reduces volume but does not change the per-incident workload. Read more about this in our piece on alert fatigue.
2. Build runbooks
Document the investigation steps for common alerts. "If this alert fires, check X, then Y, then Z." Runbooks help new team members and reduce the time experienced engineers spend on repetitive investigations. The downside is that runbooks go stale fast. Systems change, and the runbook written six months ago may no longer match reality.
3. Invest in self-healing infrastructure
Auto-scaling, automatic restarts, circuit breakers, and retry logic can handle a category of issues without human involvement. If a pod crashes and Kubernetes restarts it within 30 seconds, that does not need to page anyone. This works well for known failure modes but does not help with novel issues.
4. Shift left on reliability
Better testing, canary deployments, and feature flags reduce the number of production issues that make it past staging. This is a long-term investment that pays off over months. It does not help with the alerts you are getting today.
5. Automate the investigation step
This is the highest-leverage change. Instead of an engineer doing the investigation manually, an automated system does it immediately when the alert fires. By the time a human looks at it, the context is already gathered, the impact is assessed, and the options are laid out. This is the approach Fixter takes, and it is the focus of the next section.
The biggest lever: automated investigation
Automated investigation works by plugging into the same tools your engineers already use: log aggregators, APM tools, deployment pipelines, error trackers. When an alert fires, it runs the same investigative steps an engineer would:
- Pulls relevant logs and metrics from the affected service
- Checks if a recent deployment correlates with the issue
- Determines whether the issue affects all users or a subset
- Traces the request path to find where things break
- Checks if the issue is resolving on its own
- Compiles findings into a summary with recommended action
The result is that engineers go from "I need to investigate this alert" to "I need to review this investigation and decide what to do." That shift, from investigator to decision maker, is what makes on-call sustainable even on small teams.
For many alerts, the automated investigation finds that no action is needed, and the engineer never gets paged at all. For the rest, the engineer starts with a complete picture instead of a raw alert. Both outcomes dramatically reduce the time and cognitive load of on-call.
Key takeaways
- On-call burden scales with incident workload, not team size. Hiring does not fix it.
- Investigation accounts for the majority of on-call time and is largely automatable.
- The most effective approaches reduce per-incident work, not just alert volume.
- Automated investigation turns on-call from "first responder" into "decision maker."
Frequently asked questions
How much time does on-call actually cost a small team?
Teams consistently report that production maintenance and on-call duties consume 25 to 35% of engineering time. For a 5-person team, that is the equivalent of 1 to 1.5 full-time engineers spent on keeping things running instead of building.
Is it possible to eliminate on-call entirely?
Not entirely, no. Production systems will always have situations that require human judgment: business-critical decisions, novel failure modes, customer-facing trade-offs. The goal is not zero on-call. It is on-call where engineers only get involved when their judgment is genuinely needed, and they start with context instead of from scratch.
What is the ROI of automating incident investigation?
If your team spends 30% of their time on production maintenance and you can automate 60% of the investigation work, you recover roughly 18% of your engineering capacity. For a 5-person team at $150K average salary, that is approximately $135K per year in recovered engineering time, not counting reduced attrition and faster incident resolution.
Does this work if we do not use Datadog or PagerDuty?
Automated investigation tools like Fixter plug into whatever observability stack you already have. The specific tools matter less than having logs, metrics, and deployment history accessible. If your engineers can investigate an incident, an automated system can too.