bug: effective schedule silently changes when a job runs longer than its interval

Describe the bug

When a scheduled job takes longer than its own interval, the effective cadence changes and nothing says so. The schedule keeps displaying the configured cron expression, and there is no warning anywhere that runs are happening at a different rate than configured.

To be explicit about what is not being reported: the absence of pile-up is correct and desirable. Windmill schedules the next run only after the previous one finishes, so a slow job does not stack up or double-process. That part is good design. The report is about the silence around the resulting drift.

To reproduce

Script (bun) that takes 50 s:

export async function main() {
  await new Promise(r => setTimeout(r, 50000));
  return { done: new Date().toISOString() };
}

Schedule it with */20 * * * * * (every 20 seconds), enabled, UTC.

Observed over ~4.5 minutes:

2026-08-26T20:43:20.026761Z   (first)
2026-08-26T20:44:20.041157Z   gap 60s
2026-08-26T20:45:20.013396Z   gap 60s
2026-08-26T20:46:20.027231Z   gap 60s

Average gap: 60 s, against a configured 20 s. The behaviour is deterministic — the 50 s job finishes past the next two cron slots, so the next matching slot is always 60 s out.

Reading the schedule back afterwards:

schedule = '*/20 * * * * *'

Unchanged, with no indication that the effective rate is one third of it.

Expected behavior

Make the divergence visible. Any of these would do:

• A warning when a run's duration exceeds the schedule interval.
• An indicator on the schedule showing the effective cadence next to the configured one.
• A field on the schedule recording the last observed interval.

Screenshots

No response

Browser information

Not applicable — reproduced via API.

Application version

CE v1.796.0-12-gffdf17ef8d, image ghcr.io/windmill-labs/windmill:main, digest sha256:f8513becee64ac47b0099a84adde4bb90962f396768070671b0ab9790e343f87. Stack from the repo's own docker-compose.yml.

Additional Context

This is a condition that arises on its own over time rather than at setup. A job that initially takes two minutes and grows to twelve as data volume increases will quietly stop keeping its hourly cadence, and the only trace is timestamps drifting apart.

Two practical consequences for anyone relying on schedules:

• The number of runs in a period cannot be derived from the cron expression. Anything that counts scheduled executions has to count actual runs.
• For monitoring, the useful signal is the interval between consecutive runs, not whether the schedule is enabled — an enabled schedule running at a third of its configured rate looks healthy by every other measure.