Recurring schedules

A scheduled run fires automatically against a saved profile. Cron expressions follow standard 5-field syntax (minute hour day-of-month month day-of-week) in UTC. Examples: 0 9 * * * = 9am daily · 0 8 * * 1-5 = 8am weekdays · 30 7 * * 1 = 7:30am Mondays.

Active schedules

Name	Profile	Cron (UTC)	Date offset	Resilience	Status	Last fired	Next fire
Associate summary	Associate summary	`30 2 * * *`	1 day(s) ago	retries: 2 every 5m fallback on	enabled	2026-08-22 02:30:56.246274 last batch →	2026-08-23 02:30 UTC
Kgl daily 7Am	Db data save	`30 1 * * *`	1 day(s) ago	retries: 2 every 5m fallback on	disabled	2026-05-15 01:30:58.212790 last batch →	— (disabled)
Minimum Hours Not Met	Insufficient Hours	`50 2 * * *`	1 day(s) ago	retries: 2 every 5m fallback on	enabled	2026-08-22 02:50:57.786823 last batch →	2026-08-23 02:50 UTC
Team Summary	Team summary	`0 3 * * *`	1 day(s) ago	retries: 2 every 5m fallback on	enabled	2026-08-22 03:00:58.557829 last batch →	2026-08-23 03:00 UTC
Urgent Attention	Urgent Attention	`20 3 * * *`	1 day(s) ago	retries: 2 every 5m fallback on	enabled	2026-08-22 03:20:00.178931 last batch →	2026-08-23 03:20 UTC

Add a schedule

Name

Run profile

Cron expression (5-field, UTC)

Report date offset (days before fire date) e.g. 1 = "report on yesterday's data" (most common for daily runs)

Resilience (auto-retry on failure)

Max retries If a run fails or has QA blocks, the daemon spawns a fresh attempt up to this many times. 0 = no retries (legacy behaviour).

Retry delay (minutes) Wait this long after a failed attempt before spawning the next.

Fallback dispatch after retries exhausted If all retries still produce QA blocks, spawn ONE final attempt with QA hard-block disabled — so the email is dispatched even with warnings, instead of being completely held back. Use this when "imperfect mail going out" is better than "no mail going out".

Enabled

Note (optional)