---
title: Submissions Run Late
description: "**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? |…"
url: "https://brightleafdigital.io/docs/submissions-run-late/"
updated: "2026-10-18"
category: Recurring Form Submissions for Gravity Forms / Troubleshooting Recurring Form Submissions For Gravity Forms
---

# Submissions Run Late

**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

1. The **attempt log ID** for a late attempt.
2. **Copy Diagnostics** for that series — it carries the timing evidence.
3. 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.