Automate a weekly uptime and incident report from status pages

When a payment provider or code host has a bad afternoon, your own dashboards show symptoms, not the cause. The vendor posts an incident, marks it resolved, and the page moves on. A week later nobody remembers whether the error spike matched an outage. A weekly record fixes that: which dependency, which component, how long, and how bad. It also helps you decide which vendors deserve a fallback.

You add the job and list the status pages that matter to you. Pages hosted on Statuspage publish public JSON endpoints, including a list of the 50 most recent incidents and a list of components with states such as operational or major_outage. Each week a scheduled agent reads those feeds, keeps incidents whose dates fall in the last seven days, and records impact, duration and affected components. Where a page has no feed, it reads the page itself and says so. It reports what vendors published and does not guess at causes.

The CTO agent, as department head, reviews the report before it goes out: do durations add up, is each incident from the right service, is a suggested action safe. Then you approve, edit or skip it, and nothing is sent until you do. Start with the three or four services whose outages hurt most, and compare the report with your own memory of the week.

A status page is the vendor's own account, so treat durations as approximate and impact labels as the vendor's judgement. Use the report to spot patterns: the same component failing three weeks running is a reason to add retries, a fallback or a second provider. Keep the list of pages short and tied to real customer-facing paths, and drop a page from the job once you no longer depend on that service. A report that stays short gets read, and a read report is what lets you answer a customer who asks what happened on a given afternoon.