SwissNowWhy your ServiceNow scheduled jobs are colliding
Each job looks reasonable in isolation. Nobody's looking at the whole schedule at once.
How jobs actually collide
Scheduled jobs are almost always configured independently, by different people, at different times - nothing enforces that the full picture still makes sense together.
Same table, overlapping windows
Two jobs writing to the same records within the same run window - whichever finishes last quietly wins, and neither job knows the other exists.
Long-running jobs pushing into the next job's start time
A job that used to finish in two minutes now takes twenty, as data volume grows - and the schedule around it was never designed for that.
Retry storms
A failed job's own retry logic overlapping with its next regularly scheduled run - the same work attempted twice, concurrently.
Dependent jobs with no explicit ordering
Job B assumes job A already ran and produced its output - nothing on the platform actually enforces that assumption.
How to check
The configured schedule and the real run history tell two different stories - the conflict usually only shows up in the second one.
Read actual run windows, not just the cron expression
A job's configured schedule says when it's meant to start. Its execution history says how long it actually took, and whether that overlapped with something else - only the second one tells you what actually happened.
Look at execution history for overlap, not just failures
A job can succeed on its own and still have collided with another one writing to the same table at the same time - success doesn't mean the two runs didn't interfere with each other.
Patterns worth reviewing first
- Jobs on the same table with overlapping configured windowsThe most direct signal - two jobs scheduled to touch the same data in the same window.
- Jobs whose actual run time now exceeds the gap before the next oneFine when it was configured, not fine anymore now that data volume has grown.
- Jobs with retry logic and no backoffA failure that immediately retries can collide with the job's own next scheduled run.
- Jobs with an undocumented dependency on another job's outputWorks today because of ordering that happens to hold - not because anything guarantees it will keep holding.
The manual version doesn't scale
Reviewing this properly means reading every active job's real configured window and its actual execution history, and re-checking that comparison every time a new job is added or an old one's runtime changes. On a real instance with dozens of scheduled jobs, that's not a one-time audit - it's a standing commitment nobody has time for.
Running this check continuously, automatically
Our own platform, neo.ai, reads every scheduled job's real run window on a schedule and surfaces genuine overlaps before they collide in production - visualized on a heat map, not buried in a table nobody opens. It's one of seven categories it watches across a ServiceNow instance.