Symptom: submissions happen, but after their target time.
Some lateness is normal and by design. This page shows how much is normal, and how to find out what caused the rest.
First: How Late Is Too Late? #
| Lateness | Verdict |
|---|---|
| 0–15 minutes | Normal. The worker polls; this is the design. |
| 15–30 minutes | Worth a look. A slow pass, or a busy site. |
| Over 30 minutes | The worker is not keeping up — treat it as a worker problem. |
Thirty minutes is twice the default worker interval, which is also the threshold worker health uses, and the threshold that makes an occurrence count as a missed run.
Lateness Is Not Failure #
A late attempt that succeeds is a success.
- It does not increment the failure count.
- It does not generate a submission-failure notification.
- It does not turn into an issue.
Timing is recorded separately from outcome, deliberately.
Read the Timing Explanation #
Every new attempt records a Timing explanation, visible in attempt history and appended to the parent entry’s existing note when the attempt started after its target.
| Explanation | Meaning |
|---|---|
| Within the normal polling window | The attempt started within one worker interval of its target (normally 900 seconds). Nothing is wrong. |
| Delayed worker dispatch | The cron event was due inside the polling window, but the worker started after it. The report gives the measured event-to-worker delay and any additional wait inside that pass. |
| Within-pass wait | The worker began inside the window, but this particular attempt started after it while the pass was still working. |
| Manual submission/retry | You pressed a button. The timing isn’t attributed to cron. |
| Unknown / unavailable | The evidence doesn’t establish a cause. |
Delayed worker dispatch reports the delay; it deliberately does not claim why. Traffic, a cron lock, slow earlier cron callbacks or another server problem all look the same from inside WordPress, and guessing would be worse than reporting the measurement.
What the Evidence Contains #
Diagnostics retain:
- the original cron-event timestamp,
- the actual worker start,
- the previous completed heartbeat,
- the configured interval,
- the attempt start,
- the measured delays.
Two details worth knowing:
- WordPress normally reschedules an event before calling its worker, so the plugin observes the original timestamp first and consumes that evidence only within the current cron request. It never alters the cron filter result or adjusts a schedule for diagnostic purposes.
- Evidence is stored before submission work begins, so it survives an interrupted attempt.
Limits: older attempts are not retroactively classified, and an alternate cron runner that doesn’t expose the original event may leave the cause Unknown.
Fixing Each Cause #
Within-pass wait or many series #
The worker claims up to 50 due rows per pass and stops taking new work when its time budget runs out. With many series due at once, later ones start later.
| Fix | How |
|---|---|
| Spread the load | Stagger run times across feeds rather than putting everything at 09:00 |
| Run more often | Lower rfsfgf_worker_interval — but only if your host invokes WordPress that often |
| Reduce per-attempt cost | Heavy notifications, feeds and workflows on the form all extend each submission |
Delayed worker dispatch #
The event was due but WordPress started the worker late.
| Fix | How |
|---|---|
| Use a real server cron | Every 5–15 minutes, instead of relying on visitor traffic |
| Check for cron congestion | Slow callbacks from other plugins delay everything behind them |
| Check host throttling | Some shared hosts defer or rate-limit cron |
Everything is late by exactly one interval #
That’s polling, not a fault. If you need tighter timing, lower the interval and make the host match it.
Persistent Lateness Becomes a Missed Run #
Once an occurrence is more than twice the worker interval late:
- a feed set to run one missed occurrence submits it anyway;
- a feed set to skip declines it, records it in history with its lateness, and moves on without counting it as a success or a failure.
So chronic lateness on a skipping feed shows up as missing submissions, not as late ones. Check the missed-run policy before concluding that occurrences vanished.
What to Send Support #
- The attempt log ID for a late attempt.
- Copy Diagnostics for that series — it carries the timing evidence.
- The add-on log around that time if logging was on: worker pass start records the cron-event timestamp and previous heartbeat; pass finish records how much work there was and how long it took.
