ASHIK
12/25/2025, 7:21 PMMarvin
12/25/2025, 7:21 PMMarvin
12/25/2025, 7:27 PMexport PREFECT_API_SERVICES_LATE_RUNS_AFTER_SECONDS=60
# Restart your server so the setting takes effect
prefect server start
- Or disable the Late service entirely:
prefect server start --no-late-runs
- If you’re on Prefect Cloud:
- You can’t change the server-level Late threshold, but you can reduce noise with Automations:
- Trigger: Flow run state change → Late
- Hold “for” 1–2 minutes before notifying so brief delays don’t alert
- Or auto-cancel after N minutes if that’s preferable
- You can also adjust notification rules to ignore Late and only alert on Failed/Crash/etc.
Quick checks to confirm what’s actually Late
- List late runs:
prefect flow-run ls --state LATE --limit 50
- Inspect a specific run:
prefect flow-run inspect <run_id>
prefect flow-run logs <run_id>
- Check work pools/queues and concurrency:
prefect work-pool ls
prefect work-pool inspect <pool_name>
Review worker logs around the scheduled time to confirm the worker is polling the correct queue and not hitting concurrency limits.
Helpful docs
- Prefect docs
- Automations (add a “for” duration to Late triggers)
- States (Late vs Scheduled vs Pending)
To help pinpoint the root cause and stop the flags for good, could you share:
- Are you on Prefect Cloud or self-hosted Server?
- A couple example flow run IDs and the workspace name/slug where you’re clicking the links
- Your worker/agent Prefect version (prefect version)
- The work pool and queue names those runs are using
I can then tell you exactly why those are being marked Late and propose the minimal change to stop the false alerts.Bring your towel and join one of the fastest growing data communities. Welcome to our second-generation open source orchestration platform, a completely rethought approach to dataflow automation.
Powered by