---
title: Logging and Copy Diagnostics
description: "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.…"
url: "https://brightleafdigital.io/docs/logging-and-copy-diagnostics/"
updated: "2026-10-18"
category: Recurring Form Submissions for Gravity Forms / Troubleshooting Recurring Form Submissions For Gravity Forms
---

# Logging and Copy Diagnostics

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

1. What you expected, and what happened.
2. The **attempt log ID** from attempt history.
3. The **Copy Diagnostics** report.
4. The add-on log excerpt around that timestamp, if logging was on.
5. 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*.