# Weekly Statuspage reliability report for leadership

> Every Monday at 8am, turn last week's incidents into a trend report leadership can actually read, published to your wiki and summarized in Slack.

- Workflow type: agent
- Services: Statuspage, Confluence, Slack Bot
- Categories: Engineering, Operations
- Published: 2026-08-10

## What it does

- Pulls the past week of incidents from your status page every Monday morning, keeping real outages separate from planned maintenance so the numbers mean something
- Works out how many incidents you had, how long each one took to resolve, and which parts of your product were affected most often
- Compares this week against the week before, so leadership sees whether reliability is improving or slipping instead of reading a raw list
- Publishes the full write-up as a page in your engineering wiki, then posts the headline numbers and a link to your leadership channel

## What you'll need

- A Statuspage account with incident history on the status page you want to report on
- A Confluence space where the report should be published, usually your engineering space
- A Slack workspace and the channel your leadership team actually reads

## Prompt

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.

## How to customize

- Change when it runs, for example Friday afternoon instead of Monday morning
- Send the report to a different Confluence space, or leave it as a draft for review before anyone sees it
- Swap the leadership channel, or widen the comparison window to show a monthly trend instead of week over week

## FAQ

### Does this count scheduled maintenance as downtime?

No. Planned maintenance and real incidents live in the same place on a status page, which is why raw counts are often misleading. This report separates the two and reports them independently, so a busy maintenance week never looks like a bad reliability week.

### What happens if we had no incidents last week?

You still get a report. It states zero incidents for the week and shows how that compares with the week before, which is useful evidence of improvement rather than an empty page.

### How far back does the report look?

It covers the previous seven days in detail, and also reads the seven days before that so it can show whether things are getting better or worse. You can widen this if you want a longer trend.

### Will the whole report get dumped into Slack?

No. Slack gets a short summary with the headline numbers and a link to the full page, so the channel stays readable and the detail lives in your wiki.

### Can it publish somewhere other than Confluence?

Yes. Confluence is the natural fit since it is part of the same product family as Statuspage, but you can point the report at Notion or another documentation tool if that is where your team writes things down.

Use this prompt in General Input: https://www.generalinput.com/prompts/weekly-statuspage-reliability-report-for-leadership