Weekly Ops Review Template

Overview

Ops reviews are where teams spot trends before they become incidents. A weekly review of incidents, costs, and performance turns scattered alerts into useful patterns. Without structure, ops reviews become complaint sessions or status updates that nobody reads. What this template gives you is a repeatable shape: what happened, what it cost, what’s trending, and what we plan to do about it.

The template is deliberately table-heavy: numbers on a page are harder to argue with than impressions in a meeting. Every section maps to a single question. Summary asks how the week went, incidents ask what broke, costs ask what we spent, performance asks whether we stayed inside the SLO, actions ask what changes next week, and risks ask what might break soon.

When to Use

Use this resource when:

• Your team reacts to incidents but never analyzes patterns
• Cloud costs creep up without explanation
• You’re establishing an SRE or platform engineering practice and need a regular review cadence

Skip it when a monthly business review already covers ops health, or when the team is small enough that everyone already knows what broke this week; a five-person startup can get away with a shared channel and a Friday thread. For performance-specific deep dives, the Performance Regression Template is a better fit.

Solution

# Weekly Ops Review: `<Week of YYYY-MM-DD>`

## 1. Executive Summary

| Metric | This Week | Last Week | Trend | Target |
|--------|-----------|-----------|-------|--------|
| Incidents | `X` | `Y` | ↑ / ↓ / → | `< 3` |
| SEV 1–2 | `X` | `Y` | ↑ / ↓ / → | `0` |
| MTTR (mean) | `X min` | `Y min` | ↑ / ↓ / → | `< 30 min` |
| Cloud Cost | `$X` | `$Y` | ↑ / ↓ / → | `< $Z` |
| Error Budget Remaining | `X%` | `Y%` | ↑ / ↓ / → | `> 50%` |

**Narrative:** `One-paragraph summary of the week: biggest issue, biggest win, biggest risk.`

## 2. Incident Review

| ID | Severity | Service | Root Cause | MTTR | Action Item | Owner | Status |
|----|----------|---------|------------|------|-------------|-------|--------|
| INC-### | SEV 1/2/3 | `service` | `cause` | `X min` | `action` | `@name` | Open / Closed |

### Recurring Themes

- `Theme 1: description and frequency`
- `Theme 2: description and frequency`

### Follow-Up from Last Week

- [ ] `Action item 1` — `@owner` — `status`
- [ ] `Action item 2` — `@owner` — `status`

## 3. Cost Analysis

| Category | This Week | Last Week | Delta | Budget | Variance |
|----------|-----------|-----------|-------|--------|----------|
| Compute (EC2 / GCE) | `$X` | `$Y` | `+/- Z%` | `$B` | `+/- V%` |
| Storage | `$X` | `$Y` | `+/- Z%` | `$B` | `+/- V%` |
| Data Transfer | `$X` | `$Y` | `+/- Z%` | `$B` | `+/- V%` |
| Managed Services | `$X` | `$Y` | `+/- Z%` | `$B` | `+/- V%` |
| **Total** | `$X` | `$Y` | `+/- Z%` | `$B` | `+/- V%` |

### Cost Drivers

- `Driver 1: description`
- `Driver 2: description`

### Cost Action Items

| Action | Projected Savings | Owner | Deadline |
|--------|-------------------|-------|----------|
| | | | |

## 4. Performance & Reliability

| Service | Availability | Latency P99 | Error Rate | Saturation | Status |
|---------|------------|-------------|------------|------------|--------|
| `API` | `X%` | `Y ms` | `Z%` | `W%` | ✅ / ⚠️ / ❌ |
| `Web` | `X%` | `Y ms` | `Z%` | `W%` | ✅ / ⚠️ / ❌ |
| `Worker` | `X%` | `Y ms` | `Z%` | `W%` | ✅ / ⚠️ / ❌ |

### SLO Breaches

| Service | SLO | Actual | Budget Impact | Action |
|---------|-----|--------|---------------|--------|
| | | | | |

## 5. Action Items for Next Week

| Priority | Action | Owner | ETA | Success Criteria |
|----------|--------|-------|-----|------------------|
| P0 | | | | |
| P1 | | | | |
| P2 | | | | |

## 6. Risks & Escalations

| Risk | Likelihood | Impact | Mitigation | Escalation |
|------|------------|--------|------------|------------|
| | | | | |

Explanation

The template separates data from narrative. The tables force a quantitative review; the narrative explains what the numbers mean. Many teams skip cost analysis until the bill shocks finance; including it weekly builds cost awareness into engineering culture. The recurring themes section is where you catch systemic issues: three memory-related incidents in three weeks is a pattern, not bad luck.

If you’re building the review habit alongside an on-call rotation, the On-Call Incident Response guide covers the incident side, and the SRE Practices guide covers error budgets and SLO mechanics in depth.

Companion files: the weekly-ops-review-template companion repo has the review as a standalone Markdown file plus a summarize-week.py script that computes the executive summary table from a JSON export of incidents and costs.

Weekly Ops Review Dashboard Query

=== Weekly Ops Review Dashboard ===

Week of: 2026-07-08 to 2026-07-14

1. INCIDENT SUMMARY
   Total incidents:        3
   P0 (critical):          0
   P1 (high):              1 (auth-service timeout, 2026-07-10)
   P2 (medium):            2 (cache eviction storm, DB slow query)
   Mean time to detect:    4 min
   Mean time to resolve:   22 min
   Customer impact:        1,200 users affected (P1)

2. SLO STATUS
   Service          SLO Target   Actual    Budget Remaining
   api-gateway      99.9%        99.92%    78%
   auth-service     99.9%        99.85%    42% (trending down)
   payment-service  99.95%       99.96%    65%
   search-service   99.5%        99.51%    51%

3. COST ANALYSIS
   This week:       $12,450
   Last week:       $11,800
   Trend:           +5.5% (investigate)
   Top cost:        EC2 instances ($4,200)
   Anomaly:         S3 egress +40% (new export feature?)

4. DEPLOYMENT SUMMARY
   Total deploys:   7
   Rollbacks:       1 (api-gateway v2.3, config error)
   Hotfixes:        1 (auth-service session fix)
   Failed deploys:  0

5. RECURRING THEMES
   - auth-service latency spikes during peak (3rd week)
   - Cache eviction rate above baseline (2nd week)
   - S3 egress cost increasing (1st week, new pattern)

Action Item Tracking Template

=== Action Item Tracker ===

Week: 2026-07-08

| ID  | Priority | Action                              | Owner    | Status    | ETA         |
|-----|----------|-------------------------------------|----------|-----------|-------------|
| A01 | P1       | Investigate auth-service latency    | alice    | In Progress| 2026-07-15 |
| A02 | P1       | Fix cache eviction policy           | bob      | Open       | 2026-07-18 |
| A03 | P2       | Review S3 egress cost spike         | charlie  | Open       | 2026-07-22 |
| A04 | P2       | Update DB query with missing index  | dba-team | Done       | 2026-07-10 |
| A05 | P0       | Add alert for auth-service p99 > 2s | alice    | Done       | 2026-07-11 |

Previous Week Items:
| ID  | Action                              | Owner    | Status    |
|-----|-------------------------------------|----------|-----------|
| P01 | Reduce EC2 costs by right-sizing    | platform | Done      |
| P02 | Add synthetic test for checkout     | qa-team  | In Progress|
| P03 | Document failover procedure         | sre-team | Done      |

Running the Review

None of this works without a meeting with a fixed shape. A format that holds up in practice:

1. Data first (5 min). Fill the tables before the meeting; whoever’s facilitating pulls numbers from monitoring, incident tracking, and cost tools. The meeting discusses; it doesn’t go hunting for data.
2. Follow-up before new business (5 min). Walk last week’s action items first. If an item is two weeks stale, either it’s important enough to escalate or honest enough to close.
3. Incidents and trends (10 min). Review what broke and whether the same things keep breaking. This is where recurring themes get named.
4. Costs and performance (5 min). Skim unless something moved; a 5%+ cost swing or an SLO trending toward breach earns the floor.
5. Actions and risks (5 min). No action item leaves the room without an owner and a deadline, and risks get written down before they turn into incidents.

Two failure modes to watch: the review drifts into a status meeting (people report instead of analyze; cut it), or it quietly dies after a few good weeks (a quiet week is exactly when trend analysis pays off; keep the cadence).

Variants

Context	Focus	Cadence
Startup (< 20 people)	Incidents + cost only; skip SLO tables	Weekly, 15 min
Scale-up (20–100)	Full template; assign action item owners	Weekly, 30 min
Enterprise (100+)	Per-service reviews; aggregated monthly	Weekly per team, monthly cross-team
Platform / SRE team	Focus on shared infrastructure and tenant health	Weekly, 45 min
Cost-conscious org	Expand cost section; include per-feature costing	Weekly, 30 min

What Works

1. Keep the review under 30 minutes; long meetings kill engagement
2. Assign owners to every action item in the meeting, not after
3. Review last week’s action items first; accountability reinforces the habit
4. Use real numbers, not anecdotes; “feels slow” isn’t useful
5. Document risks before they become incidents; escalating early prevents fires

Common Mistakes

1. Turning the review into a blame session; focus on systems, not people
2. Skipping cost analysis until finance complains; costs creep silently
3. Not reviewing action items from previous weeks; this makes the meeting useless
4. Allowing “no incidents this week” to mean “no discussion needed”; always review trends
5. Not escalating risks early; waiting until a risk becomes an incident wastes the review

Troubleshooting

These are the failure modes of the review itself, when the ritual exists but isn’t producing outcomes:

• The review became a status meeting: people recite what they did instead of analyzing what the system did. Fix it by banning individual updates; the tables carry the facts, the discussion carries the meaning.
• Action items pile up unowned: every item left the meeting with a name but nobody’s closing anything. Cap the active list (10 per team works) and close or escalate anything older than two weeks; a growing list is noise, not accountability.
• Nobody trusts the numbers: the cost table and the dashboard disagree, or metrics get pulled manually with errors. Automate collection from the source APIs (monitoring, incident, cost tools) and stop hand-editing figures.
• Attendance keeps shrinking: the review got too long or too generic. Cut it to the sections that changed this week and rotate the facilitator; ownership of the meeting keeps people in it.
• The same incident keeps recurring: themes get noted but never turned into fixes. When a theme appears three weeks running, it graduates from “theme” to a tracked action item with an owner, or it stays forever.

Further Reading

• Google SRE Workbook — Implementing SLOs: the error-budget mechanics behind the Performance & Reliability section.
• DORA: the four key metrics worth adding to the executive summary once the basics are stable.
• Related templates: Performance Regression Template for latency deep-dives, Change Management Template for the deploy side.