building a morning metrics briefing as a cron job

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.

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.

   # 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.

   [ ] 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.

   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.

   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.

   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/pstVAXoNfSYwu-coqov32SKg

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

Thread query: building a morning metrics briefing as a cron job

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.