My job isn't running — troubleshooting
If a scheduled job stops firing, the cause is almost always one of a handful of things: the job is paused, the schedule or timezone is off, your endpoint is failing, or you've hit a plan limit. Work through the checks below in order and you'll usually find the answer in a minute or two.
Start with the execution history
Your single best diagnostic tool is the job's execution history. Open the job from your dashboard and look at the most recent runs.
- Is there a recent run at all? If runs simply stopped appearing, the job is likely paused or blocked by a limit (see below).
- Are runs there but marked failed? Open one and read the recorded status code and response. A non-2xx status, a timeout, a connection error, or a DNS failure all count as a failed execution.
- Look at the job status badge. A job that the circuit breaker has auto-disabled after persistent failures will show as disabled until its endpoint recovers.
Run through the checklist
- 1
Confirm the job is Active
A paused job never runs. It may be paused manually, auto-disabled by the circuit breaker after repeated failures, or paused because you hit your plan's active-job cap (the newest, over-cap jobs pause first after a downgrade). Re-enable or resume it once the underlying issue is fixed.
- 2
Check the next run time and timezone
Each job runs in its own timezone, evaluated against your cron expression or interval. A run you expected at 09:00 your local time may be set in UTC or another zone. Verify the timezone on the job and the next run time it shows. Pick UTC if you want to avoid daylight-saving ambiguity.
- 3
Verify the endpoint returns 2xx
Only a 2xx response counts as success. If the execution log shows 4xx or 5xx, fix the endpoint, auth, or request body. Failed runs retry per your retry strategy and then alert, so persistent failures mean a real problem at your end.
- 4
Make sure the URL is reachable and public
Requests are sent from CronJobPro's servers, so the target must be reachable from the public internet. A localhost address, a private internal IP, or a host that fails DNS will never succeed. Use a publicly resolvable URL.
- 5
Raise the timeout if needed
If your endpoint is slow, a low request timeout will cut the request short and record it as a failed run. Increase the per-job timeout (in seconds) to comfortably exceed your endpoint's real response time.
- 6
Check your plan limits
If you've reached your plan's daily-run cap (counted in UTC), further runs that day are skipped. Note that Run now also counts toward that quota. Higher plans allow more daily runs, more active jobs, and shorter minimum intervals.
If runs are present but always failing, the problem is your endpoint, not the schedule. Open one failed run, read its status code and response body, and reproduce that same request yourself.
A few less-obvious causes
- Overlap skip policy: if a job is set to skip and the previous run is still in flight, the new run is skipped on purpose. Long-running jobs can quietly skip back-to-back runs.
- Alert threshold: a higher alert threshold suppresses failure alerts until N consecutive failures, so the job may be failing silently. The default is 1, which alerts on the first failure.
- No alerts arriving: confirm you have at least one channel set up under Settings, Notifications (email, Slack, Discord, webhook, and more).
Still stuck after these checks? Trigger the job once with Run now to capture a fresh execution log, then compare its recorded status and response against what your endpoint returns when you call it directly.