Two evidence sources, both redacted, both safe to send to support as they stand.
Copy Diagnostics #
Where: the Copy Diagnostics button in Queue, or on an entry card.
It opens a scrollable report with Copy and Close controls. (In the no-JavaScript fallback it’s a collapsible panel.)
What’s in it #
| Included | |
|---|---|
| Plugin, WordPress, Gravity Forms and Populate Anything versions | The series’ timezone |
| The exact target | The actual attempt |
| Worker registration and heartbeat | Feed activation state |
| Series state | Safe dependency context |
| Timing evidence — cron-event timestamp, worker start, previous heartbeat, configured interval, measured delays |
What’s excluded, deliberately #
Submitted values · names · email addresses · tokens · full payloads.
That’s why you can paste it into a ticket without reviewing it first.
The Gravity Forms Add-On Log #
Enable it: Forms → Settings → Logging, then turn on logging for this add-on.
Every record carries identifiers, timestamps and outcome codes only, through the same redaction as Copy Diagnostics — so a log file can go to support unedited.
What gets recorded #
| Category | Detail |
|---|---|
| Manual actions | Every action and its outcome — including actions rejected before processing, such as an expired page token or insufficient permissions. A button that appears to do nothing still leaves a record. |
| Worker pass start | The cron-event timestamp and the previous heartbeat. |
| Worker pass finish | How many series were claimed, succeeded, failed or skipped; how long the pass took; how many locks were recovered; how much work was still queued at the end. |
| Each attempt | Claim, payload preparation (with input mode and Populate Anything dependency context), the conditional-logic decision, the child entry created, the outcome and the next target. |
| Declined missed runs | The target declined, the actual time and the lateness. Counted as skipped in the pass summary, never failed. |
| Feed lifecycle | Series paused, resumed or ended because a feed was deactivated, reactivated or deleted — otherwise the only way attempts stop with no visible action in Queue. |
| Cron event repairs | When a stale or duplicate event from an earlier version is replaced, with the previous timestamp and interval. |
| Transitions | Failure, pause-at-threshold, recovery and worker health changes, with the failure code and consecutive count. |
When to enable it #
- You need per-step detail on a specific attempt.
- A button seems to do nothing.
- Attempts stopped with no visible cause.
- Support asked for it.
Turn it off again afterwards on a busy site — it’s verbose by design.
Choosing Between Them #
| Question | Use |
|---|---|
| “What is this series’ current state and timing?” | Copy Diagnostics |
| “What happened step by step?” | The add-on log |
| “Why did this attempt start late?” | Attempt history, then diagnostics |
| “Did my click reach the server?” | The add-on log |
| “Why did submissions stop with nothing in Queue?” | The add-on log — feed lifecycle records |
A Good Support Report #
- What you expected, and what happened.
- The attempt log ID from attempt history.
- The Copy Diagnostics report.
- The add-on log excerpt around that timestamp, if logging was on.
- Whether it’s one series or all of them.
Don’t attach entry exports, screenshots showing submitted values, or credentials. Nothing in the plugin’s own reports contains them, and they aren’t needed.
If You’re Building an Extension #
The same rule applies to your own logging:
Do not log field values or full entry data.
Use rfsfgf_attempt_completed, which receives the structured result and redacted context, and rfsfgf_diagnostic_context, which is followed by the plugin’s own bounded allowlist.
See Developer Reference: Hooks and Filters.
