DevOps Operations Deck

About this template

When to use this

A 10-slide format for reporting infrastructure, deployment and incident status outside the engineering team at the end of a sprint or a month. The audience is a CTO, product leadership or executives, so it carries metrics and judgements rather than commands and configs. The cover uses periodical wording – “REPORTS”, “ISSUE 01 · 2026”, “COVER STORY” – which suits an issue number, and slide 10 closes on the line “More often, more safely”. Keep a deep postmortem in its own document and leave one line plus a link here.

Filling order

1. The four cards on slide 8 are numbered FIG. 01 to FIG. 04 and ship as “34” weekly deployments, “26 min” mean time to recover, “4.1%” change failure rate and “99.95%” availability – already the four axes an operations review wants. Keep the labels and replace the numbers.
2. Add the SLO next to each value. Example: “99.94% (target 99.9%)” removes the need to explain whether it is good.
3. There are only two body sets. Slide 4, “Deployment results”, leads with “How many releases went out this quarter, and how long they took.” over “34 deployments a week on average”, “Change failure rate from 6.8% to 4.1%” and “3.2 hours from commit to production”. Slide 6, “Build pipeline”, leads with “We found the stages where builds stalled and fixed them.” over “18 minutes to 7 by parallelizing tests”, “Cache hit rate up to 82%” and “Nightly regression tests run automatically”. Put this period’s results on slide 4 and pipeline work on slide 6 and the structure holds.
4. The agenda has five lines – “Deployment results”, “Build pipeline”, “Deployments before and now”, “Key metrics” and “Trend analysis” – plus a separate “5 items” label. Two dividers exist, PART 01 “Deployment results” and PART 02 “Build pipeline”, so agenda and deck agree. To report incidents or cost separately, duplicate a divider-and-body pair and update both the agenda line and that count label.
5. Slide 7 sets column A “Before” against column B “Now”: “Releasing once a month” to “Releasing 4 times a week”, “3 hours per release” to “11 minutes per release”, “Rollback averaging 47 minutes” to “Rollback averaging 90 seconds”. Keep the row names and swap in your own pipeline measurements.
6. The trend bars on slide 9 are labelled by month – “Apr” 96, “May” 118, “Jun” 134, “Jul” 152 – and rise to the right, which suits deploy counts; a metric that should fall needs the bar heights reversed too.

Examples

• Status example: “118 deployments (27 per week), 4 rollbacks; change failure rate 3.4%, down from 5.1%.”
• Incident example: “One P1: Feb 9, 01:12 to 02:05 (53 min), caused by connection pool exhaustion.”
• Improvement example: “Add a load-test stage to the pipeline by the second week of March – platform team.”

Definitions and captions

Change failure rate = (rollbacks + hotfixes) / deployments x 100. MTTR = mean of (recovery time – detection time); state whether you measure from detection or from onset, because the numbers differ sharply. Availability = (total time – downtime) / total time x 100, and say whether planned maintenance is excluded. The deck carries captions – “Figures are sample values. Replace them with your own numbers.” on slide 8, and “A chart of the quarterly trend, shown as an index. Values are samples.” with “Unit: index” on slide 9. Rewrite them as your measurement window and tooling instead of deleting them. Note that the caption says quarterly while the bar labels run April to July by month; align one to the other so nobody misreads the period. The bars are shapes and need manual resizing.

Common mistakes

• Reporting availability alone: a team that froze deployments posts the same number. Pair it with deployment frequency.
• Ending a root cause at traffic spike – name the limit that was hit.
• Listing improvements with no owner or date, so they reappear next month unchanged.
• Cramming six topics into two body sets; duplicating a slide beats shrinking the type.