Most small teams do ops reviews that are either skipped or turn into blame sessions. A 20-minute weekly version works better. Here is the agenda that fits on one page.
1) Top 3 incidents of the week (5 min)
Not the full timeline - just trigger, blast radius, time-to-detect, time-to-fix. If you cannot state it in one sentence, your alerting is too noisy.
2) One leading metric (3 min)
Pick ONE: p95 latency, queue depth, error budget burn, or deploy frequency. Watch the trend, not the value.
3) The recurring toil tax (5 min)
What did a human do manually that a script or runbook could do? Every item gets an owner and a date - or it gets deleted.
4) Riskiest change next week (4 min)
What ships, what it touches, what is the rollback. One sentence each. This is where you stop next week's incident before it starts.
5) Wins (3 min)
Anything that got faster, cheaper, quieter. Positive reinforcement keeps the ritual alive.
Rules that make it stick:
- Same day, same time, 20 minutes hard stop
- No slides, one shared doc
- Rotate the facilitator weekly
- Every action gets ONE owner and a date
The point is not the meeting. It is building the habit of looking at signals before they become outages. Teams that do this weekly typically see fewer repeat incidents within a month - the fixes from week N show up in week N+1's numbers.
If you want the ready-made version: a 30+ page runbook template pack with agenda docs, on-call rotation templates, and postmortem formats is here:
https://hive80lab.gumroad.com/l/ops-starter-kit
What does your weekly ops review look like? Drop your agenda below - I am collecting variations.
Top comments (0)