Weekly digest

The weekly digest is a single email to every board, manager, and admin user summarizing the building’s week. It’s the standing agenda item that writes itself: downtime, throughput, what’s being ignored, and what’s planned.

What’s in it

Per property, the digest covers the past week:

• Downtime hours, per tower and per asset - how many hours each asset (and each tower’s assets collectively) spent in unplanned downtime this week. Computed by the same uptime engine as the bars, so maintenance windows are excluded and overlapping incidents aren’t double-counted.
• Throughput counts - incidents new, resolved, and verified this week. The gap between resolved and verified is worth watching: it shows whether residents agree things are actually fixed.
• Oldest unacknowledged incidents - the list nobody wants to be on. Anything sitting in open appears here, oldest first; SLA-breached items will already have been escalated by the sweep.
• Upcoming maintenance - declared windows ahead, so the board sees the planned week.

Previewing it

/admin → Digest renders the current digest in the browser - exactly what would be sent if it ran now. Check it before wiring up the schedule, and any time you want the week’s numbers without waiting for Monday.

Delivery

The digest is sent to all board, manager, and admin users.

• With SMTP_URL set, it’s emailed (from DIGEST_FROM).
• Without SMTP, every message is written to .data/outbox/*.eml.html instead - open the file in a browser. This is the default in development and a safe way to dry-run the schedule before pointing it at real inboxes.

Running it

Two equivalent entry points, same engine:

• HTTP: POST /api/cron/digest with Authorization: Bearer ${CRON_SECRET}.
• CLI: npm run digest from apps/web - connects to the database directly, no running server required.

Crontab

Monday 08:00 is the classic choice - the week’s record, in inboxes before the week starts:

# crontab -e - weekly digest, Mondays 08:00
0 8 * * 1 curl -s -X POST -H "Authorization: Bearer dev-cron-secret" http://localhost:3000/api/cron/digest

Replace dev-cron-secret with your real CRON_SECRET and the URL with your deployment’s base URL. Pair it with the hourly SLA sweep (see SLA policy & escalation) for the full schedule:

0 * * * * curl -s -X POST -H "Authorization: Bearer dev-cron-secret" http://localhost:3000/api/cron/sweep
0 8 * * 1 curl -s -X POST -H "Authorization: Bearer dev-cron-secret" http://localhost:3000/api/cron/digest

n8n

If your building already runs n8n for automations:

1. Schedule Trigger node - Trigger Interval: Weeks, on Monday at 08:00.
2. HTTP Request node -
   • Method: POST
   • URL: https://your-condopulse.example/api/cron/digest
   • Header: Authorization: Bearer <CRON_SECRET>

Because it’s a plain authenticated POST, you can chain anything off the response - a Slack/Telegram “digest sent” confirmation, or a fallback alert if the request fails. (n8n is also the natural consumer of CondoPulse’s outgoing webhooks - see Webhooks & n8n - but the digest is pull by schedule, not webhook-driven.)

Any scheduler works the same way: launchd, systemd timers, GitHub Actions cron, your PaaS’s scheduled jobs - anything that can POST with a bearer header.

Reading the digest well

A few habits that make the digest more than wallpaper:

• Track downtime hours week-over-week for your problem assets. The 90-day bars show the pattern; the digest gives you the number to read out at the meeting.
• The “oldest unacknowledged” list should usually be empty. If the same incident appears two weeks running, that’s a process failure the SLA sweep has already escalated - ask why acknowledging it is hard.
• Watch resolved vs. verified. Lots of resolved, little verified can mean fixes aren’t sticking - or just that residents need a nudge that the Confirm fixed button exists.
• Cross-check upcoming maintenance against vendor bookings. If the elevator contractor is coming Thursday and there’s no window declared, Thursday will paint red instead of blue.

For the monthly, AGM-grade version of this - uptime per asset, SLA breach lists, costs, incident aging - use the board report at /report?month=YYYY-MM (see Exports & audit log).