Guide
Plan on-Call as Capacity, With a Budget Your Team Can Keep
On-call needs a stated budget like any other capacity. We cut the pages with alerts worth reading, tested recovery and a runbook, and help you promise only the cover you can honour.
4-minute read5 November 2026
In Brief
- When the same few people are woken, the cost appears as a quiet resignation, and the fix is applied to the person while the arithmetic of the rota is left unchanged.
- We see four actions: do the rota arithmetic first, give every page a purpose, trial new alerts before they can wake anyone, and read service commitments in your engineers' time zone.
- Thinqmesh starts from what you run, automates the release path, puts monitoring and a tested restore in place, and delivers your first automated release in four weeks.
On-call usually starts as a favour. The product goes live, someone puts their number on a spreadsheet, and the two engineers who know the system take turns. Three years later there is a paging tool and a rota, and the same few people are still being woken. We believe on-call should be designed like any other capacity plan, with a stated budget, and that when the numbers do not work, the promise made to customers is the thing to change.
The Arithmetic of a Rota Is Usually the Problem
Four engineers running a primary and a secondary are on call every second week. Drop the secondary and it becomes one week in four, with no one to call if the person holding the phone is asleep or ill. Both arrangements are hard to sustain, and attitude has nothing to do with it.
So we count pages like money. Every page must need immediate human action, new alerts run in test mode before they can wake anyone, and an alert that fires repeatedly becomes a defect with a known cost. Service commitments are read in your engineers' time zone before they are signed, because a daytime promise to a customer in another region can be a night shift for you.
Four Actions That Make on-Call Sustainable
Each action reduces the load on the people holding the phone, and the first costs nothing but an afternoon.
Do the Rota Arithmetic Before Buying Anything
Count how often each person is on call, with and without a secondary.
Four engineers running a primary and a secondary are on call every second week. Dropping the secondary brings it to one week in four, with no one to call if the person holding the phone is asleep or ill. Both arrangements are hard to sustain, and the numbers say so without any need to discuss attitude.
Get started
- Count the engineers who can really take the pager.
- Work out how many weeks in a year each of them carries it.
Give Every Page a Purpose
A page must require immediate human action. Anything a person can look at tomorrow belongs in a ticket queue.
An action that a script can take should be taken by a script. We review each alert against that test and move the rest to tickets. The result is a pager that rings when a person is needed, which makes each night shift shorter and each response faster.
Get started
- List last month's pages and mark the ones that needed a human.
- Convert the rest to tickets or automatic actions.
Trial New Alerts Before They Can Wake Anyone
A new alert runs in test mode for about a week, and its trigger rate predicts what it will do to the budget.
Pager load is recorded as structured data, including which fault caused which page, and reviewed at a regular production meeting. A page that has fired three times this month is a defect with a known cost, so we compare that cost with the cost of the fix.
Get started
- Set the number of pages per shift that triggers a review.
- Agree that threshold now, while it is easy to agree.
Read Service Commitments in Your Engineers' Time Zone
A daytime promise to a customer in another region can be an overnight shift for the people who deliver it.
Before signing, check what each commitment means at three in the morning for your own team. Offer the cover you can honour fully, write compensation down, keep schedules stable, and make swaps easy and documented.
Get started
- Convert your support hours to your engineers' local time.
- Write down what an engineer receives for a night page.
How Thinqmesh Solves This
We start from what you already run and establish only what your size justifies. Four weeks take a defined scope to your first automated release, and a restore is tested before go-live.
- Week 1
What You Run Today
We start from what you already run, and record how releases, monitoring and backups work at present, including who is paged and why.
- Week 2
The Release Pipeline
Build, test and deployment are automated for a defined scope, so that a release runs the same way every time.
- Week 3
Monitoring and Recovery
Monitoring and alerts worth reading are put in place, and a restore is tested, so that recovery is proven.
- Week 4
First Automated Release
Your first automated release goes out, with a tested route back should one be needed, and a runbook your team can follow.
You finish with an automated pipeline for a defined scope, infrastructure defined in code, monitoring with a tested restore, and a runbook your team can follow.
