Gravity Forms troubleshooting often starts after logs have rotated or after several components wrote separate files. Searching only the newest file can make a successful entry save look like a missing webhook, email, or background feed. The useful evidence is a correlated timeline built from a controlled marker, entry ID, feed ID, request ID, and UTC timestamps.
Use this when a Gravity Forms submission, notification, payment, CRM feed, webhook, or background task failed and the relevant events may sit across current and rotated logs.
Quick answer
Create one safe marker submission, record the entry and feed identifiers, then search every current and rotated Gravity Forms log for those identifiers. Normalize timestamps to UTC, sort the matching lines, and label each component boundary. The first missing or contradictory transition identifies the owner of the failure better than the last error line alone.
What to check first
- Record the form ID, unique marker, entry ID, feed ID, notification ID, provider message or request ID, and submission time.
- List current and rotated log filenames with modification time, size, component, and retention boundary.
- Search exact identifiers across Core, addon, mail, webhook, payment, and background-processing logs.
- Convert timestamps to UTC and preserve several lines before and after each matched event.
- Mark expected transitions and identify the first point where evidence stops, repeats, or conflicts.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Enable only the required Gravity Forms component logs for a time-bounded canary. | Record the form ID, unique marker, entry ID, feed ID, notification ID, provider message or request ID, and submission time. | One marker can be followed from submission through entry save, feed decision, request, response, and final state. |
| Submit the controlled marker and capture identifiers from the entry and integration. | List current and rotated log filenames with modification time, size, component, and retention boundary. | The joined timeline includes filenames, line numbers, UTC timestamps, components, and stable identifiers. |
| Build the UTC timeline across all matching current and rotated files. | Search exact identifiers across Core, addon, mail, webhook, payment, and background-processing logs. | The repeated fixture crosses the previously broken boundary exactly once. |
| Fix the first broken component boundary and repeat the same fixture. | Convert timestamps to UTC and preserve several lines before and after each matched event. | Verbose logs are disabled or time-bounded and the retained evidence is redacted. |
Why this usually happens
- Each Gravity Forms component can use a separate logger and retention behavior.
- A slow provider response or background job can cross the log rotation time.
- Support exports may sort files alphabetically instead of by the timestamps inside them.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
marker='GF-AUG09-TRACE-7812'
find wp-content/uploads -type f -iname '*log*' -print0 | xargs -0 grep -nH -E "$marker|entry.?7812|feed.?42|request.?req_abc"
# Normalize matched timestamps to UTC, then sort by timestamp.
# Preserve component, filename, line number, and correlation ID.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Entry saved, feed absent | Marker appears in Core log only | Inspect feed condition, queue, and addon logging state |
| Feed sent, response missing | Request line without provider response | Check timeout, network, provider, and rotated continuation |
| Duplicate processing | Same entry and feed run twice | Compare retry, cron, and idempotency evidence |
| Rotation boundary | Request in old file, response in new file | Join by request ID and UTC order before declaring timeout |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Enable only the required Gravity Forms component logs for a time-bounded canary.
- Submit the controlled marker and capture identifiers from the entry and integration.
- Build the UTC timeline across all matching current and rotated files.
- Fix the first broken component boundary and repeat the same fixture.
- Disable verbose logging, redact the support bundle, and confirm retention cleanup.
Decision rule
Assign the incident to the component that owns the first missing expected transition. If the request left WordPress and has a provider ID, move to provider or network evidence. If no feed invocation exists, stay with form conditions, queueing, or addon configuration.
Production verification checklist
- One marker can be followed from submission through entry save, feed decision, request, response, and final state.
- The joined timeline includes filenames, line numbers, UTC timestamps, components, and stable identifiers.
- The repeated fixture crosses the previously broken boundary exactly once.
- Verbose logs are disabled or time-bounded and the retained evidence is redacted.
Field notes
- Use an invented marker that contains no customer or payment data.
- Copy only the relevant time window and redact authorization headers, secrets, and unrelated entries.
- Keep original log files read-only and perform sorting on a working copy.
Questions teams ask during testing
Why use a marker if I have an entry ID?
The marker proves the exact controlled fixture and helps find components that omit the entry ID.
How much context should be retained?
Keep enough surrounding lines to identify component state and response, while redacting unrelated records and secrets.
Can timestamps be compared directly?
Only after confirming time zones and formats. Normalize to UTC while preserving the original value.
Mistakes to avoid
- Do not search only the latest log file.
- Do not join events by customer email or message text when stable IDs exist.
- Do not upload complete logs containing secrets and unrelated personal data.
- Do not delete rotated files before preserving the incident window.
What to tell the client or owner
Provide the marker, form and entry IDs, feed and provider IDs, UTC window, matched files, first missing transition, redaction method, and whether the repeated fixture passed.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, trace a Gravity Forms incident.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references