When a scheduled website task doesn’t run on time, first check whether it was saved for the time you intended. Then find out whether anything triggered it, and whether it started but failed before finishing. Those are different problems, and each needs a different response. Changing the schedule won’t repair a broken trigger, and repeatedly running the task can create a second problem if the first attempt already did some of the work.
I’d start with the business result you expected. A post should have appeared, a reminder should have been sent, or a file should have been produced. That gives you something concrete to trace instead of staring at a green status badge and wondering why nothing happened.
Write down the time you actually meant
Record the intended date, local time, and named timezone alongside the saved schedule. Keep the corresponding UTC time if the system provides it. A timezone name and a fixed offset aren’t interchangeable throughout the year, so a recurring task deserves a separate check around daylight-saving changes.
Then distinguish the time the task became eligible from the time it started and the time it finished. Those may be three different timestamps. If the record says the job is due at 9 a.m. but it began at 9:12, you’re investigating execution delay. If it was saved for noon instead, you’re investigating the schedule itself.
For example, suppose a reminder is intended for 9 a.m. in the customer’s location, but the automation uses the website’s timezone. Both systems can be working exactly as configured while the customer receives the wrong experience. The repair belongs in the rule that translates the customer’s intended time, not in the email template.
Find out what wakes the task up
WordPress’s normal WP-Cron mechanism checks due tasks during page loads rather than running continuously like a server scheduler. A quiet site can therefore execute a due task later than you expected. The WordPress scheduling documentation explains that distinction. Hosting arrangements and plugins can change the execution path, so confirm your site’s actual setup before applying a generic fix.
Ask whoever maintains the site to identify the trigger, its last observed run, and the evidence that it reached WordPress. If a server scheduler is involved, a configured command isn’t proof that the command succeeded. If a plugin owns its own queue, checking only the core schedule may leave out the task you’re looking for.
You don’t need to change server settings yourself to make progress. You can record the expected result, the scheduled time, and what the website shows, then give the maintainer a focused question: did this job become due, did its trigger run, and what happened next?
Follow one attempt through to its result
Look for a task identifier and the first failure associated with it. A callback error, a denied external request, or missing input calls for a different repair than a trigger that never ran. Collect the smallest useful evidence and preserve it in a website change record, including any setting you change while testing.
Before retrying, inspect the destination. Did the email go out even though the completion flag wasn’t saved? Did one record get created before the task failed? The reason automation retries can create duplicates is that failure reporting and real-world effects don’t always happen together. Don’t assume a red badge means nothing happened.
Check the next scheduled run
Use a harmless test job with a known input and an observable output. Record eligibility, start, completion, and result. For a time-sensitive workflow, agree on an acceptable delay and decide who receives an alert when that delay is exceeded. If the job works when someone runs it manually, that’s useful, but you still need to see it start on its own at the next scheduled time.
Bring in your developer or host when the investigation reaches server scheduling, queue internals, or a failing callback. Give them the exact job and evidence rather than asking them to reset every scheduled task. And after the repair, watch a real scheduled execution. Keep the timestamps and the result together so you can check what happened if the job is late again.
TechDex Presents…
Flashback to the ’90s
Get 2026 services at 1990s prices.
For a limited time, I’m rolling prices back on six focused small-business services. Choose one service for $800, or choose two for $1,200. Nothing is purchased here—I’ll review your request and confirm the scope with you first.
For related work, explore this Rewind service:
The campaign form lets you choose one or two services and request a follow-up. It isn’t a checkout, and you won’t be billed when you submit it.