What you’d get from us every month.

The monthly report shows how we did against each promise in your contract.

Illustrative exampleExample Co is not a customer. Every name, date and figure on this page is invented to show the layout of a real report.

Alerts this month

84

Across 5 production services.

Acknowledged within 15 min

84 of 84

Slowest: 11 minutes.

Assessed within 30 min

84 of 84

Slowest: 26 minutes.

Likely-cause accuracy

90%

Our first likely cause matched the cause confirmed at close.

1. Response times against your contract

We show the slowest case as well as the typical one, because an average can hide a bad night.

MeasureContractTypical3 in 4 withinSlowest
Acknowledge15 min3 min5 min11 min
Cause and severity30 min12 min16 min26 min
Your engineer picks up an escalationAgreed: 20 min8 min14 min41 min

One escalation on 14 September took 41 minutes to be picked up, because the page went to an engineer on leave. Your rota has since been updated.

2. Alert quality

Where this month’s 84 alerts went5 production services
Fixed by an approved runbook
37
Noise
16
False alarms, explained in the ticket
8
Escalated to your engineer
23
  • Closed without waking you: 61 of 84. 37 known issues fixed by an approved runbook, 16 noise and 8 false alarms.
  • Escalated to your engineer: 23. Each went with a timeline, the evidence and a likely cause.
  • Pages nobody needed to act on: 24 of 84, or 29%, down from 38% in July. The quarterly goal is 23% or lower.
  • Incidents your users spotted before an alert did: 1 of 6. Password reset emails stopped sending and no alert covered it. A synthetic check (a scripted test of the journey, run every few minutes) now does.
  • Alerts per incident: 4.2, down from 6.8. Fewer duplicate pages for the same problem.
How we count itPages nobody needed to act on = noise plus false alarms, divided by all alerts. This month: (16 + 8) ÷ 84 = 29%. Runbook fixes are not counted, because a known issue still needed fixing, even if nobody was woken for it.

3. Incidents

DateServiceWhat users sawDurationReport
3 Sepcheckout-apiSlow checkout for about 1 in 5 users17 minPublished 5 Sep
9 SepsearchEmpty search results in one region42 minPublished 12 Sep
14 SepnotificationsPassword reset emails not sent2 h 10 minPublished 17 Sep
21 Sepcheckout-apiErrors on card payments9 minPublished 23 Sep
26 SepadminAdmin pages slow for staff25 minPublished 29 Sep
29 SepimagesProduct images missing14 minDraft, due 2 Oct

Each report covers the timeline, who was affected, the contributing factors, what went well, where we got lucky and what we told your customers. The search incident on 9 September had three contributing factors: a config change, a missing check in the release pipeline and an alert that only watched error rates, not empty results.

4. Runbooks

RunbookRunsWorkedLast tested
Roll back checkout-api release2212 Aug
Scale out search workers7712 Aug
Restart image-resize worker28282 Sep
RecommendationThe image-resize restart ran 28 times, up from 9 in August. Restarting keeps it working but hides a memory leak that is getting worse. We recommend fixing the leak this quarter.

5. Reliability targets

ServiceTarget (30 days)ActualAllowance usedStatus
Checkout succeeds99.9%99.94%60%On target
Search returns results in under 500 ms99%98.7%130%Over budget

Search used more than its monthly allowance for failure, mostly in the 9 September incident. We recommend pausing risky search releases for two weeks while it recovers; you decide whether to.

6. Reliability goals this quarter

  • Cut pages nobody needed to act on to 23% or lower by 31 December. Now 29%. On track.
  • Add a reliability target for sign-up by 30 November. Draft agreed with your product lead; measurement starts 1 November. On track.

7. Follow-up actions

ActionOwnerDueStatus
Add an empty-results check to search releasesYour team15 OctOpen
Synthetic check for password resetTracefox20 SepDone
Fix image-resize memory leakYour team30 NovOpen
Remove 6 duplicate disk alertsTracefox30 SepDone

8. Changes we made, and what’s coming

  • Raised the disk alert on the reporting database from 80% to 90% full, because it paged 9 times without anyone needing to act.
  • Removed 6 duplicate disk alerts and added the password reset check.
  • Your planned move of search to a new region on 18 October: we’ll watch it closely and have the rollback runbook tested beforehand.

9. Near misses

On 25 September the TLS certificate for the payments callback was 6 days from expiring when our certificate alert caught it. Your team renewed it the same day. No users were affected; we list near misses because they show which defences are doing the work.

You build the product. Our engineers stay on call.

Book a 20-minute call We’ll look at your alerts and on-call together.
Not ready to talk? Take the two-minute readiness check
Book a 20-minute call