# Scheduled re-renders and report delivery

> Refresh a published document on a schedule, and email a link to the people who read it.

Source: /toft-docs/latest/user/build/reports/

A [document app](/toft-docs/latest/user/build/notebooks.md) shows the numbers from its last render. A
**render schedule** re-renders it on a cron expression.

## Set a schedule

1. Open the app's **Settings** tab.
2. Under **Re-render on a schedule**, enter a five-field cron expression, in
   UTC. `0 6 * * 1-5` is 06:00 UTC on weekdays.
3. Select **Schedule**. The **On** switch pauses it; **Remove** deletes it.

A re-render is a full deploy of the app's branch: the code is fetched again,
dependencies are reinstalled, and the document runs from the top. It appears
in the app's deployment history. If it fails, the published version stays up.

## Send it to people

Once a schedule exists, add recipients under **Send it to**. After each
successful scheduled render, each recipient gets an email with a link to the
app.

- **A link, never the file.** Recipients sign in as usual, so a private report
  stays private, and everyone on the list needs access to the app.
- **Only a scheduled render sends.** A failed render or a manual redeploy
  mails nobody.
- **Access is re-checked on every send.** Someone who has lost access, or has
  no email address, is skipped with a reason and stays on the list.
- **Sends are rate-limited.** A render that comes too soon after the last
  delivery is recorded as skipped.
- **Mail must be configured.** Without a mail relay on the install, every
  recipient is skipped with that reason.

The latest delivery result is shown beside the recipient list.

## Render schedule vs. a scheduled job

A render schedule rebuilds and republishes a document. A
[job](/toft-docs/latest/user/automation/jobs.md) with a schedule runs a command from your
deployment and leaves the published document as it is. Use a render schedule
to refresh what readers see; use a job for work alongside it.