Multi-instance cron

When you run more than one Sumeru process against the same database, each process starts the built-in scheduler (scheduler.Start in core/server/run.go).

Safe concurrent execution

Due cron rows are selected inside a transaction with:

SELECT … FROM sys_cron
WHERE active AND (next_call IS NULL OR next_call <= $now)
ORDER BY id
FOR UPDATE SKIP LOCKED
LIMIT 20

Only one instance locks a given row; others skip locked rows. After the handler runs, next_call and last_call are updated in the same transaction.

Operational guidelines

1. Keep clock sync — use NTP on all app hosts; cron uses UTC.
2. Do not mix different Sumeru versions on the same database during cron-heavy windows.
3. Long handlers — if a cron handler exceeds the tick interval, the next window picks up where scheduling left off; avoid blocking handlers longer than a few seconds.
4. Outbox drain — each replica also runs StartOutboxDrain; rows are drained once via published_at IS NULL updates (idempotent publish).

For heavy cron load, prefer dedicated worker processes with -stop-after-init module ops disabled and HTTP disabled (future sumeru worker CLI), or external queue consumers fed by the outbox queue topic.

See also

• Events & cron
• Scale-out architecture
• Scheduler concept

Sumeru is pre-alpha (no tagged release, no upgrades). Part of Project Meru.