What happens when the worker wasn’t running at the scheduled time — and why the answer is never “catch up on everything”.
The Foundation #
A series holds one next target. Not a queue.
So when the worker comes back after an outage, there is exactly one overdue target to decide about. The Missed runs feed setting decides what to do with it.
Neither option ever creates one submission per missed occurrence. There is no setting that does, because there is no backlog for one to read.
The Two Policies #
Run one missed occurrence, then continue (default) #
- The overdue occurrence is submitted once.
- The series then continues at its next future time.
- The successful count rises by one.
Example: a daily 11:00 series whose worker stopped for five days creates one child entry on recovery — not five.
This is also exactly how every feed behaved before the setting existed, so updating the plugin changed nothing until you deliberately choose otherwise.
Skip missed occurrences and continue at the next future time #
- Nothing is submitted for the outage.
- The occurrence is recorded in attempt history, with its target, actual time and lateness, so the gap stays auditable.
- Successful and consecutive-failure counts are unchanged.
- The series continues at its next future time.
A skipped missed run behaves exactly like a conditional skip: it neither consumes a count limit nor counts toward the failure threshold.
Choosing Between Them #
| Choose run one when | Choose skip when |
|---|---|
| Every scheduled period must produce a record | A late record would be misleading |
| The submission is a task or reminder that’s still useful late | The submission is time-sensitive — a daily reading, a dated check |
| Counting matters more than timing | Timing matters more than counting |
What Counts as “Missed” #
Ordinary lateness is not a missed run. A healthy worker polls, so occurrences normally start a few minutes after their target — that’s the design, not a fault.
An occurrence is only treated as missed once it is more than twice the worker interval late:
| Worker interval | Missed threshold |
|---|---|
| 15 minutes (default) | 30 minutes |
| 5 minutes | 10 minutes |
That’s the same threshold worker health uses to decide the worker isn’t keeping up — so “the worker was not running” means the same thing in both places.
Developers can change the window with rfsfgf_missed_run_grace. It can never be set below one worker interval, because that would make normal polling look like an outage.
What the Policy Does Not Apply To #
| Situation | Behaviour |
|---|---|
| Run Next Submission Now | Always submits, however late the target is. |
| Retry Failed Submission | Always submits. |
| Resume after a pause | Skips the paused interval entirely and takes the next future slot — under either policy. |
| Feed reactivation | Same: the deactivated interval is skipped, never replayed. |
Missed-run policy governs automatic execution only. A button you pressed is not a missed run.
Where You Can See It #
- Queue and the entry card include the skip policy in the schedule summary, so a series that skips says so.
- Attempt history records every declined occurrence with its target, actual time and lateness.
- The add-on log records declined occurrences, and counts them as skipped in the worker pass summary — never as failed.
Changing the Policy Later #
- Changing the feed setting affects new series.
- Existing series keep the policy recorded in their own snapshot.
- To move existing series to a new policy, apply the saved feed schedule to them.
A Worked Timeline #
A daily 11:00 series set to run one missed occurrence. The host’s cron dies on Monday evening and is fixed on Saturday morning.
| Day | What happened |
|---|---|
| Mon 11:00 | Submitted normally |
| Tue–Fri 11:00 | Worker not running. Nothing submitted. |
| Sat 09:40 | Cron restored; worker resumes |
| Sat ~09:45 | One overdue occurrence submitted |
| Sat 11:00 | Next scheduled occurrence proceeds normally |
Successful count rises by one for the outage, not four. Had the feed been set to skip, the Saturday-morning submission wouldn’t have happened at all, and history would record the declined occurrence instead.
