# Weekly reliability report from CloudWatch to Notion

> Every Monday morning, get a plain-English rundown of last week's alarms, incidents, and app health, filed straight into your Notion reliability database.

- Workflow type: agent
- Services: Amazon CloudWatch, Notion
- Categories: Engineering, Operations
- Published: 2026-07-17

## What it does

- Runs automatically every Monday at 7am and pulls the full picture of last week's reliability from Amazon CloudWatch.
- Walks the last seven days of alarm activity so you know exactly what fired, how often it fired, and how long each incident lasted.
- Compares your key application metrics (error rate, p95 latency, request volume) against the prior week so trends are impossible to miss.
- Writes a staff-engineer-style narrative with a green / amber / red headline, the top three incidents, a trend section, and a 'what we should do next' recommendation.
- Files the report as a brand-new page in your Notion 'Weekly Reliability' database so the exec team reads it in the tool they already open.

## What you'll need

- An AWS account with Amazon CloudWatch and read access to the alarms and metrics you care about.
- A Notion workspace with a database set up to collect the weekly reliability reports.
- The names of the application metrics you track (for example an error rate, a p95 latency, and a request volume metric) and their CloudWatch namespaces.

## Prompt

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.

## How to customize

- Change the schedule (for example Friday afternoons for a week-in-review instead of Monday mornings).
- Swap in the exact metrics that matter for your stack — you can track more than three, or focus on a single critical service.
- Adjust the thresholds behind the green / amber / red headline (for example how many minutes of alarm time flips a week from green to amber).
- Point it at a different Notion database, or add extra fields like on-call owner or product area to the created page.

## FAQ

### Does this replace our incident management tool?

No. This is a weekly executive summary that lives alongside your normal alerting. Your on-call channels and incident tool still handle real-time response — this workflow reads what already happened and writes a readable narrative for leadership.

### How does it decide if a week is green, amber, or red?

The agent looks at how much of the week was spent in an alarm state, how severe the incidents were, and how the tracked metrics moved week over week. You can tune the exact thresholds after the first few runs to match how your team thinks about severity.

### Can it cover more than one AWS account or region?

Yes. Point it at each account and region you want covered, and the report will combine the alarms and metrics into a single weekly page. You can also split into one page per account if that reads better for your execs.

### Will it work if we do not have every metric it mentions?

Yes. Tell it which metrics you actually track and it will use those. If you only have request volume and error rate, the report will focus on those and skip anything you have not set up.

### What if last week was completely quiet?

You still get a page. The headline reports the week as green, the incidents section says nothing meaningful fired, and the trend section still compares metrics against the prior week so you catch slow drifts before they become alarms.

Use this prompt in General Input: https://www.generalinput.com/prompts/weekly-reliability-report-from-cloudwatch-to-notion