Weekly Statuspage reliability report for leadership

Every Monday at 8am, build a reliability report from my Statuspage incident history so our leadership team sees the trend instead of a wall of individual incidents.

Start by looking up my status pages so you are reporting on the right one, since incident data is scoped to a specific page. Then use the Statuspage "Get a list of incidents" operation to pull every incident from the previous seven days. Also pull the seven days before that, so you can compare the two weeks and show direction of travel rather than a standalone number.

Important detail to get the numbers right: incidents and scheduled maintenances share the same underlying record in Statuspage. Realtime incidents use the statuses investigating, identified, monitoring, and resolved. Scheduled maintenances use scheduled, in_progress, verifying, and completed. Select realtime incidents by that first status set, and count them separately from scheduled maintenance so planned work never inflates the incident numbers. Report maintenance as its own line.

For the reporting week, work out how many real incidents occurred, how long each one stayed unresolved before it reached resolved status, the median and the longest time to resolve, which components were hit most often, and whether any themes repeat week over week. Each incident carries a list of updates that grows every time the incident is updated, so use those update timestamps to derive when the incident opened, when each status change happened, and the total duration.

Page through the results politely. Pagination is offset based using page and limit with a maximum of 100 per page, and the API allows about one request per second before it returns an HTTP 420 rate limit response with an empty body. Space the requests out, advance the page number until an empty array comes back, and back off and retry if you are rate limited.

Write the report as clear prose for a leadership audience rather than an engineering changelog. Lead with the headline numbers and the comparison against the prior week, say plainly whether reliability improved or slipped, then give the supporting detail: incident count, resolution times, most affected components, repeating themes, and scheduled maintenance shown separately. Publish it as a Confluence page in our engineering space using Create Page, titled with the week ending date.

Finally, post the headline numbers and a link to the published Confluence page into our leadership channel using the Slack Bot "Send a Message" action. Keep the Slack message to a few lines, since the full detail lives in Confluence.

If there were no real incidents in the reporting week, still publish the page and still post to Slack, stating zero incidents and noting how that compares with the prior week.