# 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*.

<!--
Guidance: How to use this template
- Run the review once a quarter, in the second week after the quarter
  closes, so ticket and paging data is complete. Book 60 to 90 minutes
  with the team, its engineering manager and the product owner who
  competes for the same engineering time.
- Collect data before the meeting (section 4). The meeting is for
  decisions, not for counting.
- Present toil per engineer as well as per team. A team average under
  the cap can hide one or two people who carry most of the load.
- Use pseudonyms (E1, E2 and so on) when the document is shared beyond
  the team. The purpose is to fix the work, not to rate people.
- Related documents: On-call Handbook (`ops/on-call-handbook`), Alerting
  Policy (`ops/alerting-policy`), Incident Severity Matrix
  (`ops/incident-severity-matrix`), Capacity Plan (`ops/capacity-plan`),
  Error Budget Policy (`ops/error-budget-policy`), SLO document
  (`dev/slo-doc`), Runbook (`dev/runbook`), Developer Experience Survey
  (`dev/developer-experience-survey`).
- Worked example: the platform reliability team of Corvid Commerce, a
  fictional SaaS company. Rows marked *Example* belong to it.
-->

## Document control

<!-- Guidance: Identify the team, the period and the people who own the decisions. -->

| Field | Value |
|---|---|
| Document ID | [TOIL-YYYY-QN-TEAM] |
| Team | [Team name] |
| Review period | [YYYY-MM-DD to YYYY-MM-DD] |
| Review meeting | YYYY-MM-DD |
| Version | [0.1] |
| Status | [Draft / Reviewed / Decisions agreed / Closed] |
| Owner | [@engineering-manager] |
| Approvers/reviewers | [@sre-lead], [@product-owner], [@director-of-engineering] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Toil cap in force | [Percentage of available engineering time, agreed on YYYY-MM-DD] |
| Previous review | [TOIL-YYYY-QN-TEAM] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Engineering manager | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| SRE lead | [@name] | [Decision] | YYYY-MM-DD |
| Product owner | [@name] | [Decision] | YYYY-MM-DD |
| Director of engineering | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Data collected and draft written |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Decisions agreed in the review meeting |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Automation candidate AUT-004 deferred to next quarter |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Executive summary](#1-executive-summary)
2. [Scope and period](#2-scope-and-period)
3. [Toil definition and classification rules](#3-toil-definition-and-classification-rules)
4. [Measurement method](#4-measurement-method)
5. [Toil share per engineer](#5-toil-share-per-engineer)
6. [Page and interrupt load](#6-page-and-interrupt-load)
7. [On-call health](#7-on-call-health)
8. [Toil inventory](#8-toil-inventory)
9. [Automation candidates ranked by return](#9-automation-candidates-ranked-by-return)
10. [Capacity headroom check-in](#10-capacity-headroom-check-in)
11. [Decisions](#11-decisions)
12. [Follow-up of previous actions](#12-follow-up-of-previous-actions)
13. [Glossary and references](#13-glossary-and-references)

## 1. Executive summary

<!-- Guidance: Five to eight sentences for a director: toil trend, who is over the cap, the paging picture, the top automation decisions and what they cost. Pitfall: a summary that reports only the team average. -->

[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.

| Measure | Previous quarter | This quarter | Target *(Example)* | Status |
|---|---|---|---|---|
| Team toil share *(Example)* | 29.8% | 33.5% | 40% or less | Met, rising |
| Engineers above cap *(Example)* | 1 of 6 | 2 of 6 | 0 | Not met |
| Pages per 12-hour shift *(Example)* | 1.31 | 1.55 | 2 or fewer | Met |
| Actionable page share *(Example)* | 70.2% | 66.1% | 80% or higher | Not met |
| Nights with an out-of-hours page *(Example)* | 38.5% | 44.6% | 25% or less | Not met |

## 2. Scope and period

<!-- Guidance: Define whose time is measured and for which period, including leave and part-time. Questions: who is on the team, who joined or left, which rotations did they cover? Pitfall: counting nominal hours for an engineer who was on leave half the quarter, which makes their toil share look low. -->

| Item | Value |
|---|---|
| Team and services | [Team], [services or platforms operated] |
| Period | [Quarter, start and end dates] |
| Working weeks in period | [N] |
| Nominal hours per engineer | [Weeks x contracted weekly hours] |
| On-call rotations covered | [Rotation names and shift length] |
| Engineers measured | [N, pseudonymised E1 to EN] |

*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

<!-- Guidance: Agree the definition with the team once, write it down, and apply it the same way every quarter. Questions: does someone have to do it by hand, is the recipe already known, will it come back, who triggers it, and is anything better afterwards? Pitfall: calling every unpleasant task toil, or calling nothing toil because "it is part of the job". -->

### 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)*:

| No. | Test | Question for the team | Counts toward toil when | Example that counts | Example that does not |
|---|---|---|---|---|---|
| 1 | Hands on keyboard | Does the task stall until a person types, clicks or approves something? | Yes | Approving each production promotion in the pipeline UI | A promotion that proceeds when checks pass |
| 2 | Known recipe | Could a new team member finish it from a written checklist without asking anyone? | Yes | Granting a standard read-only role from an approved request | Deciding whether a new supplier may hold customer data |
| 3 | Comes back | Will the same request or alert return within the next quarter? | Yes | Weekly reset of the shared QA environment | A one-off move of a database to a new region |
| 4 | Someone else's clock | Is the timing set by a queue, an alert or another team, rather than by the team's own plan? | Yes | Answering a disk-full ticket raised by a product team | Scheduling a storage redesign in the quarterly plan |
| 5 | Lasting change | When the task is finished, is the service permanently better: fewer future occurrences, faster, or safer? | No | Restarting a worker that hangs | Fixing the defect that makes the worker hang |

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

| Category | Description | Where it is tracked |
|---|---|---|
| Engineering | Work that leaves a lasting improvement: automation, design, fixing root causes | Project or product backlog |
| Incident response with learning | Diagnosing a new failure and writing the postmortem | Postmortem (`dev/postmortem`) |
| Overhead | Meetings, planning, hiring, training, administrative tasks | Not measured here, but shown in section 5 as non-engineering time |
| On-call availability | Being reachable while on call with nothing to do | Counted in on-call health (section 7), not as 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

<!-- Guidance: Use more than one data source and say how they were combined. Questions: how is time captured, how complete is it, and how are gaps estimated? Pitfall: relying only on self-reported estimates at the end of the quarter, which tend to understate interrupt work. -->

### 4.1 Data sources

| Source | What it gives | Coverage *(Example)* | Weakness |
|---|---|---|---|
| Ticket system, toil label | Count and logged time of request and interrupt tickets | 612 tickets, time logged on 81% | Time not logged on every ticket |
| Paging system | Pages, timestamps, acknowledgement, shift | All 286 pages | No time spent per page |
| Calendar sampling | Random two-week time diary per engineer, once a quarter | 6 of 6 engineers | Small sample |
| Pull request and pipeline data | Manual approvals and release steps | All releases | Does not show waiting time |
| Quarterly survey | Perceived toil, on-call strain | 6 of 6 responses | Subjective |

### 4.2 Calculation

```text
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

<!-- Guidance: Show every engineer against the cap, plus the team figure. Questions: who is above the cap, why, and is it the same people every quarter? Pitfall: a cap applied only to the team, so the people carrying queues burn out while the average looks healthy. -->

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.

| Engineer | Available hours | Toil hours | Toil share | Cap *(Example)* | Status | Main sources |
|---|---|---|---|---|---|---|
| E1 *(Example)* | 480 | 211 | 44.0% | 40% | Above | Release approvals, access requests |
| E2 *(Example)* | 520 | 182 | 35.0% | 40% | Within | Alert triage |
| E3 *(Example)* | 440 | 198 | 45.0% | 40% | Above | Access requests, data fixes |
| E4 *(Example)* | 500 | 120 | 24.0% | 40% | Within | Certificate rotations |
| E5 *(Example)* | 520 | 156 | 30.0% | 40% | Within | Capacity tickets |
| E6 *(Example)* | 400 | 92 | 23.0% | 40% | Within | Environment resets |
| **Team** | **2,860** | **959** | **33.5%** | **40%** | **Within** | |

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

| Quarter | Team toil share | Engineers above cap | Note |
|---|---|---|---|
| 2026-Q1 *(Example)* | 36.1% | 2 | Cap agreed |
| 2026-Q2 *(Example)* | 29.8% | 1 | Deploy automation shipped |
| 2026-Q3 *(Example)* | 33.5% | 2 | New region added access and capacity work |
| [Quarter] | [N%] | [N] | [Note] |

## 6. Page and interrupt load

<!-- Guidance: Measure the load the on-call engineer carries per shift, not per month. Questions: how many pages per shift, how many out of hours, how many needed action, and which alerts produced the most? Pitfall: counting incidents instead of pages, which hides alert storms and noisy alerts. -->

### 6.1 Paging

| Measure | Formula | Value *(Example)* | Target *(Example)* |
|---|---|---|---|
| Pages | Count in period | 286 | n/a |
| Shifts | Days x shifts per day | 92 x 2 = 184 | n/a |
| Pages per shift | Pages / shifts | 286 / 184 = 1.55 | 2 or fewer |
| Shifts above target | Shifts with more than 2 pages / shifts | 31 / 184 = 16.8% | 10% or less |
| Highest pages in one shift | Maximum | 9 | Investigated if above 5 |
| Out-of-hours pages | Pages between 22:00 and 07:00 local / pages | 104 / 286 = 36.4% | 25% or less |
| Actionable pages | Pages that needed human action / pages | 189 / 286 = 66.1% | 80% or higher |

### 6.2 Top paging sources

| Alert | Pages | Actionable | Action |
|---|---|---|---|
| *Example:* Queue depth high, order events | 58 | 9 | Re-tune to SLO burn rate per the Alerting Policy (`ops/alerting-policy`) |
| *Example:* Node disk above 85% | 41 | 30 | Automate log rotation and volume growth |
| *Example:* Synthetic check failure, single location | 37 | 4 | Require two locations before paging |
| *Example:* Certificate expiry within 14 days | 22 | 22 | Automate renewal (AUT-003) |
| [Alert name] | [N] | [N] | [Action] |

### 6.3 Interrupts outside paging

| Measure | Value *(Example)* |
|---|---|
| Interrupt tickets in period | 612 |
| Business days | 64 |
| Interrupt tickets per business day | 612 / 64 = 9.6 |
| Share handled by the person on interrupt duty | 71% |

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

<!-- Guidance: Combine load data with what engineers report. Questions: are people sleeping, taking time off after heavy shifts, and willing to stay on the rotation? Pitfall: looking only at averages, when one bad week can drive someone to leave. -->

| Indicator | Value *(Example)* | Threshold *(Example)* | Status |
|---|---|---|---|
| Nights with at least one page between 22:00 and 07:00 | 41 of 92 = 44.6% | 25% or less | Above |
| Engineers with two or more consecutive disturbed nights | 4 of 6 | 0 | Above |
| Recovery time off taken after disturbed nights, per the On-call Handbook (`ops/on-call-handbook`) | 9 of 14 eligible | All eligible | Below |
| Rotation size | 6 (about 31 shifts each per quarter: 184 / 6 = 30.7) | [Agreed minimum] *(Example: 8 or more for a single-site 24-hour rotation; 6 or more per site for follow-the-sun)* | Below |
| Survey: "on-call load is sustainable" (1 to 5) | 2.8 | 3.5 or higher | Below |
| Engineers asking to leave the rotation | 1 | 0 | Watch |

*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

<!-- Guidance: List each recurring toil task with its volume and cost. Questions: which tasks consume the most hours, which are growing, and which have an owner outside the team? Pitfall: an inventory of task names without volumes, which cannot drive prioritisation. -->

| Toil ID | Task | Category | Occurrences per quarter | Hours per quarter | Trend | Source of demand | Growth driver |
|---|---|---|---|---|---|---|---|
| TOIL-001 *(Example)* | Manual release approval and promotion | Release | 107 | 214 | Rising | Product teams | Number of services and releases |
| TOIL-002 *(Example)* | Page handling for repeating, known alerts (97 of them non-actionable) | Alerting | 286 | 187 | Rising | Monitoring configuration | Number of monitored services |
| TOIL-003 *(Example)* | Access requests for standard roles | Access | 316 | 158 | Rising | All engineering teams | Engineering headcount |
| TOIL-004 *(Example)* | Manual scaling and quota tickets | Capacity | 61 | 121 | Flat | Product teams | Traffic and regions |
| TOIL-005 *(Example)* | Production data fixes on request | Data | 46 | 115 | Flat | Support | Customer count |
| TOIL-006 *(Example)* | Certificate and secret rotation | Security hygiene | 48 | 96 | Flat | Expiry calendar | Number of services and certificates |
| TOIL-007 *(Example)* | Test environment resets | Environments | 34 | 68 | Falling | QA | Number of QA test cycles |
| **Total** | | | | **959** | | | |

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

<!-- Guidance: Estimate the return of each candidate with the same formulas and rank by them. Questions: how many hours will the automation free each year, what does it cost to build and keep running, and how soon does it pay back? Pitfall: automating the most interesting task rather than the most expensive one, or ignoring maintenance cost. -->

### 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.

```text
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

| Rank | Candidate | Toil ID | Y | Reduction | H | B | M | N | Payback | First-year net | Return ratio |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | AUT-002 *(Example)* Alert tuning: burn-rate alerts, multi-location synthetics | TOIL-002 | 748 | 70% | 523.6 | 80 | 16 | 507.6 | 1.9 months | 427.6 | 5.45 |
| 2 | AUT-001 *(Example)* Self-service access for standard roles with automatic expiry | TOIL-003 | 632 | 90% | 568.8 | 120 | 24 | 544.8 | 2.6 months | 424.8 | 3.95 |
| 3 | AUT-003 *(Example)* Automated certificate and secret rotation | TOIL-006 | 384 | 95% | 364.8 | 160 | 20 | 344.8 | 5.6 months | 184.8 | 2.03 |
| 4 | AUT-005 *(Example)* Self-service environment reset | TOIL-007 | 272 | 80% | 217.6 | 100 | 12 | 205.6 | 5.8 months | 105.6 | 1.94 |
| 5 | AUT-004 *(Example)* Automatic release promotion on passing checks | TOIL-001 | 856 | 60% | 513.6 | 320 | 40 | 473.6 | 8.1 months | 153.6 | 1.43 |
| [N] | [AUT-NNN] | [TOIL-NNN] | [Y] | [%] | [H] | [B] | [M] | [N] | [months] | [hours] | [ratio] |

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:

| Factor | Effect on ranking |
|---|---|
| Out-of-hours load and burnout risk | Move up candidates that remove night pages |
| Security or compliance risk of the manual task | Move up candidates that remove error-prone manual handling of secrets or access |
| Dependency on another team | Move down, or convert into a request to that team |
| Toil that should be eliminated, not automated | Prefer removing the demand (for example a product change) over automating it |

*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

<!-- Guidance: Confirm that toil and automation plans fit the team's capacity, and note signals for the service Capacity Plan. Questions: after toil, on-call and overhead, how many engineering hours remain, and do approved automations fit? Pitfall: approving automation work without removing other commitments, so it never starts. -->

| Item | Hours next quarter *(Example)* |
|---|---|
| Available hours (6 engineers, 13 weeks, after planned leave) | 2,960 |
| Expected toil (current rate 33.5%, before automation savings) | 992 |
| Overhead (meetings, hiring, training, estimated 15%) | 444 |
| Remaining engineering hours | 1,524 |
| Approved automation build hours (AUT-001, AUT-002, AUT-003) | 360 |
| Hours left for product and platform roadmap | 1,164 |

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

<!-- Guidance: Record each decision with an owner and date, including the decision not to act. Questions: which automations are funded, which roadmap items move to make room, and who protects the time? Pitfall: decisions without traded-off roadmap work, which turn into wishes. -->

| Decision ID | Decision | Owner | Due | Trade-off |
|---|---|---|---|---|
| TR-D-01 *(Example)* | Build AUT-002 and AUT-001 in Q4 weeks 1 to 6 | [@sre-lead] | 2026-11-13 | Observability dashboard refresh moves to Q1 |
| TR-D-02 *(Example)* | Build AUT-003 in Q4 weeks 4 to 10 | [@security-platform-engineer] | 2026-12-11 | None, inside remaining hours |
| TR-D-03 *(Example)* | Rotate the release approval queue weekly across all six engineers until AUT-004 ships | [@engineering-manager] | 2026-10-12 | E1 and E3 load drops below cap |
| TR-D-04 *(Example)* | Ask product teams to own data fix requests through a self-service tool request | [@product-owner] | 2026-12-31 | Product backlog item added |
| TR-D-05 *(Example)* | Defer AUT-004 to Q1 with a joint plan with the delivery platform team | [@director-of-engineering] | 2027-01-15 | Release toil stays at about 214 h per quarter |
| TR-D-06 *(Example)* | Request two more engineers for the rotation, or move night cover to a second site, in the next headcount cycle | [@engineering-manager] | 2026-12-15 | Until then, no new service joins the rotation without an alert review |
| [TR-D-NN] | [Decision] | [@owner] | YYYY-MM-DD | [Trade-off] |

## 12. Follow-up of previous actions

<!-- Guidance: Check whether the last quarter's decisions were delivered and whether they saved what was expected. Pitfall: never measuring the saving, so the team cannot tell good estimates from bad ones. -->

| Previous decision | Delivered | Expected saving | Measured saving | Note |
|---|---|---|---|---|
| *Example:* TR-D-01 of 2026-Q2, automated deploy rollback | Yes, 2026-08-04 | 90 h per quarter | 72 h per quarter | Rollback still needs manual approval at night |
| *Example:* TR-D-03 of 2026-Q2, page deduplication | No | 40 h per quarter | 0 | Carried over as part of AUT-002 |
| [Decision ID] | [Yes / No / Partly] | [Hours] | [Hours] | [Note] |

## 13. Glossary and references

<!-- Guidance: Define terms the way this review uses them. -->

### 13.1 Glossary

| Term | Meaning in this review |
|---|---|
| Toil | Hands-on operational work with a known recipe that keeps returning and leaves the service no better (section 3.1 tests) |
| Growth driver | What makes a toil task's volume rise, recorded in the inventory |
| Toil cap | The maximum share of available engineering time the team agrees to spend on toil |
| Available hours | Contracted hours minus leave, holidays and training |
| Page | A notification that requires the on-call engineer to respond now |
| Actionable page | A page where a person had to take an action that could not be skipped |
| Interrupt | Unplanned request or ticket that breaks planned work, outside paging |
| Return ratio | Hours freed per year divided by build plus yearly maintenance hours |
| Payback | Months until hours freed exceed build hours |

### 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.