Toil Percentage Calculator

Work out toil percentage instantly with clear inputs, formula shown and shareable results.

About Toil Percentage Calculator

Toil is manual, repetitive, automatable work that scales with service size and produces no lasting value. Google's SRE practice caps it at 50 percent of time, because beyond that there is no capacity left to build the automation that reduces it — the team becomes an operations team by default and the ratio only gets worse.

Formula

Toil accounting

toil share = toil hours / total hours; excess = toil hours - target hours; weeks to fix = excess / automation hours available per week

Worked example

With the default values below, Toil Percentage Calculator returns Share of time spent on toil of 40.0%. Change any input above and every figure here is recalculated in your browser.

Inputs used

Engineering hours per weekminimum 1 h: 240 h
Hours spent on toilminimum 0 h: 96 h
Toil targetaccepts 1–100 %: 50 %
Hours available for automation workminimum 0 h: 40 h

Results

Share of time spent on toil: 40.0%
Toil hours above target: 0.0 h
Hours left for engineering work: 144.0 h
Weeks of automation work to reach the target: 0.0 weeks

Step by step

1Values used
2Toil accounting
3Share of time spent on toil= 40.0
4Toil hours above target= 0.0 h
5Hours left for engineering work= 144.0 h
6Weeks of automation work to reach the target= 0.0 weeks

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

What counts as toil?

Work that is manual, repetitive, automatable, tactical, devoid of enduring value and scales linearly with service growth. Debugging a novel failure is not toil; running the same restart runbook weekly is.

Why cap it at 50 percent?

Above that, the team cannot invest in reduction. The cap is a forcing function that turns automation from a nice-to-have into a scheduled requirement.