Toil Review Template (Quarterly Operational Load and Automation ROI)

Toil Review: [Team name] [Quarter YYYY-QN]

Quarterly review of a team's operational load: how toil is defined and measured, toil share per engineer against an agreed cap, page and interrupt load per on-call shift, on-call health, the toil inventory, automation candidates ranked by return on investment, a capacity headroom check-in, and the decisions taken. Toil is a term from site reliability engineering practice; the Google book Site Reliability Engineering is cited by name only, and the definition tests, method and numbers in this template are original. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Executive summary
2. Scope and period
3. Toil definition and classification rules
4. Measurement method
5. Toil share per engineer
6. Page and interrupt load
7. On-call health
8. Toil inventory
9. Automation candidates ranked by return
10. Capacity headroom check-in
11. Decisions
12. Follow-up of previous actions
13. Glossary and references

1. Executive summary

[Summarise the team's toil share and trend, engineers above the cap, page load and out-of-hours load, the top automation investments approved, the engineering time they take and the expected saving.]

Example: In 2026-Q3 the Corvid Commerce platform reliability team spent 959 of 2,860 available hours on toil, a team share of 33.5%, below the team's 40% cap but up from 29.8% in Q2. Two of six engineers (E1 at 44.0% and E3 at 45.0%) were above the cap, both because they carried the release and access-request queues. On-call engineers received 286 pages over 184 twelve-hour shifts (1.55 per shift), and only 66.1% of pages needed action. The team approved three automation investments for Q4 (AUT-002 alert tuning, AUT-001 self-service access and AUT-003 certificate rotation), costing 360 build hours and expected to free about 1,457 hours a year gross (1,397 net of maintenance) once in place. Release promotion automation (AUT-004) was deferred to Q1 because of its 8-month payback.

2. Scope and period

Example: Corvid Commerce platform reliability, 2026-07-01 to 2026-09-30, 13 weeks at 40 contracted hours, so 520 nominal hours per engineer. Six engineers in one primary rotation with two 12-hour shifts a day (184 shifts in the 92 days from 1 July to 30 September). E6 joined on 2026-07-13 and has 400 available hours.

3. Toil definition and classification rules

3.1 Working definition

For this review, toil is hands-on operational work that follows a recipe the team already knows, keeps coming back, and leaves the service no better once it is done. The opposite is engineering: work that changes the service so the same need arises less often, or not at all, however tedious that work feels while doing it. The term comes from site reliability engineering practice (see the Google book Site Reliability Engineering, cited by name only); the tests below are this team's own operational rules, not a restatement of that book.

Classify each recurring task with the five tests. A task is toil when test 5 is answered "No" and at least two of tests 1 to 4 are answered "Yes" (Example rule, set your own):

Record one more attribute for every task in the inventory (section 8), without using it as a test: the growth driver, meaning what makes the volume rise (traffic, customers, services, engineers, regions). A task whose driver grows faster than the team is the first candidate for automation even when its hours are modest today.

3.2 What is not toil

Repeated response to the same known incident, where nothing new is learned, is toil. The first diagnosis of a novel failure is not.

4. Measurement method

4.1 Data sources

4.2 Calculation

Available hours (engineer)  = Nominal hours - leave - public holidays - training days
Toil hours (engineer)       = Logged toil ticket time
                            + Pages x mean handling time per page
                            + Unlogged ticket time estimated from the time diary ratio
Toil share (engineer)       = Toil hours / Available hours
Team toil share             = Sum of toil hours / Sum of available hours
Annualised hours            = Quarterly hours x 4  (assumes stable volume; state if not)

Example: For tickets without logged time, Corvid Commerce used the median logged time of tickets with the same label. For pages, it used a mean handling time of 39.2 minutes per page from the time diaries, so 286 pages x 39.2 / 60 = 187 hours. Time spent diagnosing a novel failure for the first time is excluded and recorded in the postmortem.

4.3 Data quality

[Record known gaps: tickets without labels, missing time logs, engineers without a diary sample, changes in labelling since the previous quarter. State whether the gaps change any conclusion.]

5. Toil share per engineer

The cap is the highest share of available time the team agrees to spend on toil, so that enough time remains for engineering work that reduces future toil. Example: Corvid Commerce set a cap of 40% for this team in 2026-Q1; set your own cap with your engineering leadership and record the date it was agreed in Document control.

Arithmetic (Example): available hours 480 + 520 + 440 + 500 + 520 + 400 = 2,860; toil hours 211 + 182 + 198 + 120 + 156 + 92 = 959; 959 / 2,860 = 33.5%. E1: 211 / 480 = 44.0%. E3: 198 / 440 = 45.0%.

5.1 Trend

6. Page and interrupt load

6.1 Paging

6.2 Top paging sources

6.3 Interrupts outside paging

An interrupt rota (one named engineer per day or week who absorbs tickets) protects the rest of the team's focus time. If the share handled by that person is low, interrupts are leaking to everyone.

7. On-call health

Example: The out-of-hours load comes mostly from the queue depth and single-location synthetic alerts (section 6.2). Both are noisy alerts, so alert tuning (AUT-002) is the fastest way to improve sleep, ahead of any larger automation. The rotation is also below the team's agreed minimum size for a single-site 24-hour rotation; the engineering manager takes this to the next headcount planning cycle (TR-D-06).

8. Toil inventory

Arithmetic (Example): 214 + 187 + 158 + 121 + 115 + 96 + 68 = 959, equal to the team toil hours in section 5.

9. Automation candidates ranked by return

9.1 Formulas

Apply the same formulas to every candidate so the ranking is fair. Use hours rather than money unless finance supplies a loaded hourly cost.

Annual toil hours (Y)        = Quarterly hours x 4
Hours freed per year (H)     = Y x expected reduction
Build hours (B)              = Estimated one-off effort
Maintenance hours/year (M)   = Estimated upkeep
Net hours per year (N)       = H - M
Payback (months)             = B / (N / 12)
First-year net hours         = N - B
Return ratio (rank key)      = H / (B + M)

9.2 Ranked candidates

Check for AUT-001 (Example): Y = 158 x 4 = 632; H = 632 x 0.90 = 568.8; N = 568.8 - 24 = 544.8; payback = 120 / (544.8 / 12) = 2.6 months; first-year net = 544.8 - 120 = 424.8; ratio = 568.8 / 144 = 3.95. Approved candidates AUT-002, AUT-001 and AUT-003 cost 80 + 120 + 160 = 360 build hours and free 523.6 + 568.8 + 364.8 = 1,457.2 hours a year.

9.3 Non-financial factors

Rank by return, then adjust for factors the formula does not capture, and record each adjustment:

Example: AUT-003 ranks third on return but removes manual secret handling, so it was approved in the same quarter as the top two. AUT-004 has the largest toil pool but the longest payback and needs the delivery platform team, so it moves to Q1 with a joint plan.

10. Capacity headroom check-in

Arithmetic (Example): 2,960 x 0.335 = 991.6, rounded to 992; 2,960 x 0.15 = 444; 2,960 - 992 - 444 = 1,524; 1,524 - 360 = 1,164.

Service capacity signals for the Capacity Plan (ops/capacity-plan): [record any toil that is really a capacity problem, for example manual scaling tickets that show autoscaling limits are too low].

11. Decisions

12. Follow-up of previous actions

13. Glossary and references

13.1 Glossary

13.2 References

• Beyer, Jones, Petoff and Murphy (eds.), Site Reliability Engineering, O'Reilly, 2016; online edition at https://sre.google/books/ (CC BY-NC-ND 4.0). Cited by name only, as the origin of the term toil.
• Related templates: On-call Handbook (ops/on-call-handbook), Alerting Policy (ops/alerting-policy), Incident Severity Matrix (ops/incident-severity-matrix), Error Budget Policy (ops/error-budget-policy), Capacity Plan (ops/capacity-plan), SLO document (dev/slo-doc), Developer Experience Survey (dev/developer-experience-survey), Delivery Performance Report (dev/delivery-performance-report).

Standard and licence note

Structure aligned with site reliability engineering practice for measuring and reducing toil. The Google book Site Reliability Engineering is cited by name only, as the origin of the term: its online edition is licensed CC BY-NC-ND 4.0 and its second edition is all rights reserved, so no text, list, figure, threshold or number from it is reproduced. The five classification tests in section 3 are original operational rules written for this template and do not restate the book's description of toil. The formulas, thresholds, ranking method and the Corvid Commerce example are original and fictional; every target value is an example to be replaced by your own. Check the current editions of the cited books before relying on them. Google is a trademark of its owner; this template is not affiliated with or endorsed by it. Template licence: MIT.