Weekly reliability report from CloudWatch to Notion

Every Monday at 7am, generate a plain-English weekly reliability report for the exec team from Amazon CloudWatch and file it as a new page in a Notion database called "Weekly Reliability". The audience is a non-technical VP, so write the way a staff engineer would explain the week out loud, not the way a monitoring tool would render it.

Start by pulling the full alarm inventory from Amazon CloudWatch using Describe Alarms. Then, for each alarm, use Describe Alarm History over the last seven days to build a picture of what fired, how many times it went into alarm state, and how long each incident lasted (state transitions from OK to ALARM back to OK). Aggregate this into a compact summary per alarm: name, number of incidents, total minutes in alarm, and the longest single incident.

Also pull the key application metrics the team cares about using Amazon CloudWatch Get Metric Data for the same seven-day window: error rate, p95 latency, and request volume. Ask for the prior seven-day window as well so you can compare week over week. If the operator has specified different metric names or namespaces, use those instead — treat the three above as sensible defaults.

Now write the narrative. Structure it exactly like this, in plain prose paragraphs and short bullet lists — no code blocks, no raw JSON, no metric IDs:

• A one-paragraph headline that labels the week green, amber, or red and explains the call in one or two sentences. Green means nothing meaningful fired and the tracked metrics look healthy. Amber means at least one real incident or a notable regression in a tracked metric. Red means a sustained or user-visible outage, or a sharp regression across multiple metrics.

• The three most important incidents of the week. Rank by user impact and duration, not by alarm count. For each one, write a short paragraph: what fired, when, how long it lasted, and a one-line plain-English guess at what it probably meant (for example "the checkout error-rate alarm fired for 22 minutes on Wednesday afternoon, which lines up with the deploy at 2:47pm"). If fewer than three incidents happened, say so honestly.

• A trend section on the tracked metrics. For each metric, give the current week's value, the prior week's value, and the direction of the change in plain terms ("error rate ticked up from 0.4 percent to 0.7 percent, small but worth watching"). Do not dump numbers without interpretation.

• A "what we should do next" section with two or three concrete recommendations. These are the things a staff engineer would suggest at the end of a Monday review: investigate a specific alarm, tune a threshold that is clearly too noisy, look into a metric that has drifted three weeks running, or say explicitly that no action is needed this week.

File the finished report as a new page in the Notion "Weekly Reliability" database using Create a Page. The page title should be "Weekly reliability report — week of <Monday date>". Put the green/amber/red label as a property on the page if the database has a status field for it, and put the full narrative in the page body. Keep the body scannable: use headings for the four sections (Headline, Top incidents, Metric trends, What we should do next) and short paragraphs. No raw alarm IDs, no metric IDs, no code — this is going to a VP.

Rules to follow: never invent alarms or metric values, only report what CloudWatch actually returned. If the alarm inventory is empty or a metric has no data for the window, say so in the report rather than fabricating a story. Times should be in the operator's timezone if known, otherwise UTC labelled as such. Keep the whole report tight — a VP should be able to read it in under three minutes.