## TL;DR
A morning briefing is a script that pulls yesterday's numbers, fills a markdown template, and drops the result where you will read it before standup. Build the template first with last week's data by hand, then automate the fills one section at a time. The briefing earns its keep the first morning it surfaces a problem you would not have checked for.

```text
building a morning metrics briefing as a cron job
```

## Use this when
- You start most days by opening four analytics tabs
- You run an autonomous operation and need a daily heartbeat with numbers
- A founder or team wants a consistent daily snapshot
- You keep meaning to check metrics daily but skip it under load
- You already have the data pulls and need the last mile to your eyes

## Not for this skill when
- You need alerts within minutes of an incident (that is monitoring, not a briefing)
- The metrics themselves are undefined (define them first, different skill)
- Nobody will read it; an unread briefing is a cron job burning goodwill
- You need a fancy dashboard; this skill is deliberately low-tech

## Steps
1. Write the briefing template by hand using last week's real numbers. Sections: headline numbers vs last week, what changed and why you think so, open questions, today's watch items. If you cannot fill it by hand, automation will not save it.
   ```text
   # Morning briefing [date]
   ## Headlines (vs last 7d avg)
   ## What moved and why
   ## Open questions
   ## Watch today
   ```
   Expected output: a template filled once manually. Success check: reading it takes under three minutes and you know what to do next.

2. Automate one section at a time, starting with headlines. Each data pull becomes a small script that outputs one section's numbers; the assembler just concatenates. One section per day of work keeps it shippable.
   ```text
   [ ] headlines automated and match the manual numbers
   [ ] movers section automated
   [ ] watch items automated or templated
   ```
   Expected output: sections flipping from manual to automatic. Success check: automated numbers match the hand-filled version for three days straight.

3. Schedule it to finish before you wake up, with failure alerts. The cron line runs the pulls, then the assembler, then delivery; any step failing pages you (or your agent loop) instead of delivering a half-empty briefing.
   ```bash
   30 6 * * * [HOME]/... >> [HOME]/... 2>&1
   ```
   Expected output: a briefing waiting at 06:30 daily. Success check: three consecutive days delivered on time with complete sections.

4. Deliver it where you actually look. A markdown file in a known path, a message in your main channel, or an email; pick the one you open before coffee. Fancy delivery you ignore is worse than a plain file you read.
   ```text
   delivery: [file path | channel | email]
   read check: I opened it [ ] yesterday [ ] today
   ```
   Expected output: a delivery target you genuinely use. Success check: you can recall yesterday's headlines without reopening it.

5. Prune it monthly. Kill sections nobody acts on, add the one number everyone asks about. A briefing that never changes is a briefing nobody reads; the monthly prune is the feature.
   ```text
   monthly review: sections kept [n], killed [n], added [n]
   ```
   Expected output: a changelog habit for the briefing itself. Success check: at least one section changed in the last two reviews.

## Variant phrasings
### Daily metrics report automation
Report phrasing. Steps 1 through 3: template, automate sections, schedule before wake-up.

### Cron job that emails me KPIs every morning
Email phrasing. Step 4 with email delivery; keep the body plain text or simple markdown so it renders everywhere.

### Morning standup briefing for a solo founder
Solo phrasing. Emphasize step 1: the "what moved and why" section is the whole value when the reader is also the analyst.

### Agent daily heartbeat with numbers
Agent-ops phrasing. The briefing doubles as a liveness check: no briefing means the pipeline or the agent is down.

## Why it happens
Metrics you have to go fetch get fetched when things feel wrong, which is exactly when the baseline is missing. A briefing inverts the default: the numbers come to you, so anomalies arrive with context instead of as surprises. The template-first approach works because automating a report nobody would read by hand just produces unread output faster.

## Edge cases / pitfalls
- Partial data is worse than no briefing if it is unlabeled. If a pull fails, say which section is stale rather than silently showing yesterday's numbers as today's.
- Time zones will bite you. "Yesterday" must be defined in the business's timezone, and daylight-saving transitions will shift your cron by an hour twice a year.
- Do not add real-time sections to a daily briefing. Mixing cadences makes both worse; incidents belong in alerting.
- If the briefing ever cries wolf two mornings in a row, fix the thresholds that day. Trust lost in a briefing is not regained by accuracy later.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VAX_oNfSYwu-coqov32SKg