Gravity Forms support requests often arrive with either no logs or a large archive full of unrelated personal data. A useful bundle connects one controlled submission to the exact component log, system report, request timeline, mail or feed result, and cleanup record.
Use this for failed notifications, slow submissions, add-on feed errors, spam classification, background processing, payment feeds, and conditional logic defects.
Quick answer
Enable logging only for Gravity Forms Core and the affected add-ons, run one uniquely labeled test, copy the system report, capture the entry and downstream timeline, redact secrets and personal data, then disable logging and delete the files after support confirms receipt.
What to check first
- Write a one-sentence expected result and exact reproduction steps before enabling logs.
- Enable Core plus only the affected add-on or integration logging components.
- Submit a controlled entry with a unique support marker and non-sensitive fixture data.
- Export the system report and join entry, notification, feed, queue, and provider timestamps.
- Redact credentials and personal data, record retention, then disable and delete logging.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Define the failed stage and expected result. | Write a one-sentence expected result and exact reproduction steps before enabling logs. | The bundle reproduces one issue with a unique marker and clear expected result. |
| Enable only the necessary logging components. | Enable Core plus only the affected add-on or integration logging components. | Every included file covers the same UTC window and site environment. |
| Run one uniquely marked reproduction and collect joined evidence. | Submit a controlled entry with a unique support marker and non-sensitive fixture data. | Secrets, customer data, and unrelated entries are removed or masked. |
| Redact and package the minimal support bundle with UTC timestamps. | Export the system report and join entry, notification, feed, queue, and provider timestamps. | Logging is disabled and server log files are deleted after the handoff. |
Why this usually happens
- Logging is enabled globally even when one component owns the problem.
- A support export lacks a unique marker, so events cannot be joined to one submission.
- Logs are left active after debugging even though they can contain sensitive data in plain text.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp gf tool system-report > gravity-forms-system-report.txt
# Submit marker SUPPORT-8241 with safe fixture data.
rg -n 'SUPPORT-8241|ERROR|WARNING' wp-content/uploads/gravity_forms/logs/
# Redact secrets and personal data, transfer securely, then disable logging.
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 |
|---|
| Core submission | Unique marker SUPPORT-8241 | Entry created and marker appears in Core log |
| Notification | Dedicated test recipient | Mail event joins to entry and provider result |
| Add-on feed | Fixture that satisfies feed logic | Feed log shows decision, request, and response class |
| Cleanup | Logging disabled after export | Log files removed and warning no longer shown |
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.
- Define the failed stage and expected result.
- Enable only the necessary logging components.
- Run one uniquely marked reproduction and collect joined evidence.
- Redact and package the minimal support bundle with UTC timestamps.
- Disable logging, delete log files, and document the cleanup.
Decision rule
If the Core log stops before entry creation, keep the investigation in submission validation. If an entry exists but the downstream feed or mail event is absent, move to that component. Do not send unrelated log archives hoping support will find the sequence.
Production verification checklist
- The bundle reproduces one issue with a unique marker and clear expected result.
- Every included file covers the same UTC window and site environment.
- Secrets, customer data, and unrelated entries are removed or masked.
- Logging is disabled and server log files are deleted after the handoff.
Field notes
- Gravity Forms rotates log files at its size limit, so include the relevant rotated file when the timestamp crosses a boundary.
- The system report can explain PHP, WordPress, database, memory, plugin, and cron context without a separate screenshot set.
- Use test data that exercises the real conditional logic while remaining safe to share.
Questions teams ask during testing
Which logs should be enabled?
Enable Gravity Forms Core and only the add-ons involved in the failing path.
Should the system report be included?
Yes, after reviewing it for sensitive environment details and limiting distribution.
When should logs be deleted?
After the needed evidence is transferred securely and support confirms it is usable.
Mistakes to avoid
- Do not leave Gravity Forms logging enabled indefinitely.
- Do not send production customer entries when a fixture can reproduce the problem.
- Do not include passwords, API secrets, authorization headers, or complete payment data.
- Do not rely on screenshots when searchable text logs and IDs are available.
What to tell the client or owner
Name the bundle with site, issue, and UTC window. Put expected result, reproduction, marker, affected form ID, entry ID, and log list in a short README.
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, prepare a Gravity Forms diagnostic bundle.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references