Overview
One cron-scheduled task currently lives under Core. It’s facet-taggedinternal in the codebase (matching how the admin endpoints dashboard groups it) but it reads and writes the campaign_weekly_stats table used by dashboard analytics — cross-cutting enough that it’s separated from Campaigns here.
snapshot-weekly-stats
| Schedule | Every Monday at 00:00 UTC |
| Cron | 0 0 * * 1 |
| Facet | internal |
| File | trigger/snapshot-weekly-stats.ts |
stats object into the campaign_weekly_stats table, keyed by Monday’s date. This is what powers the week-over-week delta in Load analytics for the dashboard — without these snapshots the dashboard can only show all-time totals, not weekly trend.
The task paginates campaigns in batches of 1000 to avoid PostgREST’s default row limit, and is safe to retry on partial failure (snapshots are idempotent on (campaign_id, week_start)).
What an agent should know. Dashboard analytics are meaningful only after at least two Mondays have elapsed since a campaign launched. A freshly-launched campaign will have an empty or single-point weekly series until at least one cron fires.Cross-facet by intent. The task reads
campaigns and writes campaign_weekly_stats, but it’s tagged internal in withCorrelation because the cost-tracking bucket is “platform maintenance” — no per-user credits involved. If you’re looking for this from the Campaigns side, Campaigns → Background jobs cross-references it.Related:- Load analytics for the dashboard — the consumer of these snapshots.
- Campaigns → Background jobs — for
sync-account-status, the other cron directly affecting campaigns.