Drill — Audit the Toil

Wavelength's Checkout Reliability team — the team that owns checkout-api throughout this course's capstone — just finished a rotation week, and the team lead wants a real toil number for the quarterly capacity review, not a vibe. You've been handed the raw on-call log: fourteen entries, every page, ticket, and meeting logged with a timestamp and minutes spent. Your job, in order: (1) classify every single entry as toil, engineering project work, or overhead, using the exact six-gate test and three-bucket model from Reducing Toil — not a gut call; (2) turn the correctly classified entries into a real toil percentage and check it against Google's 50% ceiling from toil & automation; (3) name the single highest-leverage automation investment the data actually supports. This page assumes you already know the six gates and the toil/overhead/engineering three-bucket split — it drills applying them under a full week of realistic, occasionally misleading data, the same way a real capacity review would hand it to you.

The scenario: Checkout Reliability's on-call week

☺ Like you're 10: One team, one pager, one week — every page, ticket, and meeting they touched, logged with exactly how many minutes it took.

The Checkout Reliability team owns checkout-api and its background worker payment-worker — the service that reconciles asynchronous webhooks from the external payment processor against checkout-api's order records — plus on-call coverage for a legacy internal admin panel and the customer-success escalation queue when a ticket needs an engineer, not just a support agent. This is the same checkout-api the course's capstone builds end to end; nothing about its SLO or architecture changes here. Below is the full raw log for the week of Monday 2026-08-10 through Sunday 2026-08-16, exactly as it was pulled from PagerDuty, the ticket queue, and the on-call engineer's own notes — nothing pre-filtered, nothing pre-labeled.

Total logged time across all fourteen entries: 623 minutes, a little over ten hours, inside a nominal 40-hour week. Resist the urge to eyeball a verdict from this table alone — Step 1 below is the whole point of this drill, and at least three entries here are built specifically to fail a gate you might not think to check.

Step 1 — classify every entry

☺ Like you're 10: One prior question sorts out the paperwork, then six yes/no questions sort everything else into toil or not.

Run each entry through Reducing Toil's exact test: first, the prior question — is this about operating the production service, or not? — which sorts administrative work into overhead before the six gates ever apply. Then, for anything that survives that question, all six gates (manual, repetitive, automatable, tactical, no enduring value, O(n) with growth) must hold, or it isn't toil.

Here's the worked verdict for every entry:

Step 2 — quantify the toil percentage

☺ Like you're 10: Add up only the entries that actually passed all six gates, divide by everything logged, and compare that one real number to the 50% line.

Summing the correctly classified entries: Toil = 36 + 35 + 40 + 37 + 105 = 253 minutes (payment-worker restarts 36, cert rotation 35, region DNS onboarding 40, three MFA resets 37, two customer provisionings 105). Everything else — the investigation, the meeting, the deploy approval, the self-healed cache blip — sums to 370 minutes and isn't toil under the formal test.

Toil (correctly classified)         =  253 min
Not toil (engineering + overhead +
  judgment call + already-automated) =  370 min
──────────────────────────────────────────────
Total logged this week              =  623 min

Toil % of total logged time = 253 ÷ 623 = 0.4061 = 40.6%   ← under the 50% ceiling

40.6% is under the ceiling — but a single week isn't the quarter-averaged number Google's policy is actually built on, and the composition matters more than the headline figure. Split the 253 toil minutes by what drives their volume:

Hold the fixed and lumpy toil (71 + 40 = 111 min) and the 370 non-toil minutes constant, and grow only the customer-count-coupled slice (142 min) at the stated 25% per quarter:

This is a deliberately simplified model — it holds the fixed, lumpy, and non-toil load flat and grows only the two customer-count-coupled sources — but the direction is the real takeaway regardless of exactly which quarter it lands in: left alone, this team's toil ratio crosses the 50% ceiling in roughly three quarters, driven entirely by enterprise-customer growth the team doesn't control, with zero change in the defect count, headcount, or engineering discipline. That's the case for acting on Step 3 now, before the number crosses, not after.

Step 3 — the single highest-leverage automation

☺ Like you're 10: Pick the toil source that's both the biggest slice right now and the one that keeps growing on its own — not just the one that paged the most times.

It's tempting to pick payment-worker — it fired three separate pages this week, more than any other single toil source. Resist that instinct: raw page count isn't leverage.

Recommendation: automate customer provisioning. Replace the nine-step, three-console manual checklist with a parameterized Terraform module triggered automatically the moment a contract is signed — climbing straight from rung 1 to rung 4, with a clear path to rung 5 once the team trusts it unattended:

# modules/customer-onboarding/main.tf
variable "customer_id" { type = string }
variable "tier"        { type = string }  # "standard" | "enterprise"

resource "aws_db_instance" "customer_schema" {
  identifier        = "cust-${var.customer_id}"
  engine            = "postgres"
  instance_class    = var.tier == "enterprise" ? "db.r6g.large" : "db.t4g.medium"
  allocated_storage = 20
  db_name           = "customer_${var.customer_id}"
}

resource "aws_iam_role" "customer_role" {
  name               = "customer-${var.customer_id}-role"
  assume_role_policy = data.aws_iam_policy_document.trust.json
}

resource "null_resource" "billing_webhook" {
  provisioner "local-exec" {
    command = "curl -X POST https://billing.internal/api/webhooks -d '{\"customer_id\":\"${var.customer_id}\"}'"
  }
}

# .github/workflows/onboard-customer.yml — fired by the CRM's "contract signed" webhook
on:
  repository_dispatch:
    types: [contract-signed]
jobs:
  provision:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          terraform init
          terraform apply -auto-approve \
            -var="customer_id=${{ github.event.client_payload.customer_id }}" \
            -var="tier=${{ github.event.client_payload.tier }}"
        working-directory: modules/customer-onboarding
      - run: curl -X POST "$SLACK_WEBHOOK" -d '{"text":"Provisioned '"${{ github.event.client_payload.customer_id }}"'"}'

That's rung 4 on day one — the system detects the trigger and runs unattended, with a Slack post so a human still notices. It removes the full 105 minutes this week cost, and because it's coupled to the same growth driving the projection in Step 2, it removes a proportionally larger number every quarter after — the automation pays for itself faster the longer it's deferred, which is exactly the ROI case toil & automation's section on building the case for automation investment describes. Secondary recommendation, not this drill's top pick but worth flagging separately: get payment-worker's memory leak onto the next sprint's postmortem action-item list — see reliability economics for how to frame that cost trade-off next to the provisioning automation for the same review.