Render cycle

What it is#

The render cycle is the full automated motion from "schedule fires" to "brief delivered." For a typical monthly brief, the cycle looks like:

1. Schedule fires (e.g., 1st of month at 9am client time)
2. Data pull — fetch fresh values from every connected source referenced in the template
3. Token resolution — replace every {{token}} in the template with the current value
4. Block rendering — generate charts, tables, metric tiles
5. Brand application — apply per-client visual theme
6. Approval routing — notify reviewers, hold for sign-off
7. Delivery — once approved, send to recipients via email + portal link
8. Audit log entry — record the entire cycle

For a 30-client roster on a monthly cadence, that's 30 render cycles per month, each running automatically.

What can go wrong#

Render-cycle failures cluster into three categories:

• Data source unavailable: the upstream API (GA4, HubSpot, etc.) is down or rate-limited
• Stale credentials: OAuth tokens expired, API keys revoked
• Schema drift: the source changed its data shape (column renamed, metric deprecated)

SendBriefs handles each with a fallback path: cache previous-cycle values if upstream is unavailable, notify the workspace admin if credentials are stale, surface a soft warning if schema drift is detected.

Approval as part of the cycle#

In most agency workflows, the render cycle pauses at the approval step rather than delivering directly. Drafts get sent to the agency-internal reviewer first, then to the client-side reviewer, then to the audience.

This means "render" and "deliver" are intentionally decoupled in the cycle — the system renders the brief on schedule but waits for the approval flow before sending.

In SendBriefs specifically#

Render cycles run on Vercel serverless compute, with Upstash queue for scheduling. Every brief has a render log visible to workspace admins showing exactly what happened, in what order, with timestamps.