Gravity Forms can mark an entry as spam through the honeypot, submission-speed checks, Akismet, reCAPTCHA, AbuseIPDB, another add-on, or a custom filter. The newest Gravity Forms troubleshooting guide provides specific log messages, but production logs can contain personal data and should be enabled narrowly.
Use this when valid leads, customers, job applicants, or support requests appear in Spam, disappear from normal notifications, or fail only for certain networks, devices, or form paths.
Quick answer
Start with the entry notes, reproduce once with a controlled test identity, and enable only the core and suspected add-on logs for that window. Find the first component that marks the entry as spam, correct that rule, retest a good and bad case, then disable logging and delete the logs.
What to check first
- Record the form ID, entry ID, timestamp, entry note, page URL, AJAX state, user state, browser, network type, and which notifications or feeds were skipped.
- Enable Gravity Forms core logging and only the relevant anti-spam add-ons, then reproduce with synthetic values that do not contain customer data.
- Read the log in order for honeypot emptiness, version_hash, submission speed, abort filters, gform_entry_is_spam, Akismet, reCAPTCHA, AbuseIPDB, and third-party decisions.
- Change one suspected setting or integration at a time and retest one expected-valid submission plus one deliberately invalid control.
- Disable logging, delete generated logs, verify notifications and feeds, and document the final rule with an owner and review date.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Read the entry note | Record the form ID, entry ID, timestamp, entry note, page URL, AJAX state, user state, browser, network type, and which notifications or feeds were skipped. | The valid synthetic case lands in normal entries and completes its intended feeds. |
| Enable narrow logging | Enable Gravity Forms core logging and only the relevant anti-spam add-ons, then reproduce with synthetic values that do not contain customer data. | The deliberately invalid control remains blocked or marked as spam. |
| Find the first spam decision | Read the log in order for honeypot emptiness, version_hash, submission speed, abort filters, gform_entry_is_spam, Akismet, reCAPTCHA, AbuseIPDB, and third-party decisions. | Logs identify the decision owner and contain no retained customer data after cleanup. |
| Retest one variable | Change one suspected setting or integration at a time and retest one expected-valid submission plus one deliberately invalid control. | Notifications, webhooks, CRM feeds, and confirmation behavior match the final entry classification. |
Why this usually happens
- Cached or customized form markup can omit the version hash expected by newer honeypot checks.
- Very fast automated-looking submissions can come from password managers, accessibility tools, or custom frontend code.
- Multiple anti-spam add-ons can evaluate the same entry and the first visible note may not explain the original trigger.
- Logs can rotate at 5 MB and hide earlier evidence if every add-on is enabled during high traffic.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
case_id: GF-SPAM-27
form_id: 14
entry_id: 9032
entry_note_reason: honeypot
version_hash_present: false
submission_speed_valid: true
akismet_result: not_evaluated
recaptcha_result: valid
expected_classification: not_spam
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Read the entry note
- Enable narrow logging
- Find the first spam decision
- Retest one variable
- Remove logs and monitor
Decision rule
Change the smallest rule that explains the controlled false positive. Keep at least one bad control blocked, and do not weaken all spam protection because one path is misconfigured.
What to tell the client or owner
Share privacy-safe form and entry IDs, timestamp, entry note, environment, enabled components, ordered log lines, one-variable test, good and bad control results, downstream feed behavior, and cleanup confirmation.
Production verification checklist
- The valid synthetic case lands in normal entries and completes its intended feeds.
- The deliberately invalid control remains blocked or marked as spam.
- Logs identify the decision owner and contain no retained customer data after cleanup.
- Notifications, webhooks, CRM feeds, and confirmation behavior match the final entry classification.
Mistakes to avoid
- Do not enable every log indefinitely on a busy production form.
- Do not paste raw entries, IP addresses, tokens, or uploaded files into a public ticket.
- Do not disable honeypot, reCAPTCHA, Akismet, and custom filters at the same time.
- Do not forget that moving an entry out of Spam may not automatically replay every feed.
Questions teams ask during testing
Where are Gravity Forms log files stored?
Gravity Forms documents the path under wp-content/uploads/gravity_forms/logs for FTP access. Log filenames use a secure random hash, and logging should be disabled and deleted after the investigation.
Why is no View Log link shown?
Gravity Forms says the link appears only when logging is enabled and the log is not empty. Reproduce the controlled case after enabling the correct component.
When HandL WP should help
HandL WP can isolate Gravity Forms false positives without broadly disabling protection, then verify notifications, CRM feeds, and privacy-safe log cleanup.
If this is active on a production site, diagnose Gravity Forms spam false positives.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Exact Gravity Forms spam reasons
For a honeypot entry note that says the hash is absent, use the missing version_hash false-positive fix. For empty or invalid timing data, use the submission-speed spam test. If the reCAPTCHA log reports a quota bypass, use the reCAPTCHA quota bypass audit to verify provider state and fallback controls.
False-positive calibration and recovery
For score-based false positives, use the Gravity Forms reCAPTCHA threshold calibration to model the tradeoff from labeled samples. After restoring a valid entry, decide each message with the notification regeneration checklist and check every destination with the external record deduplication audit before replay.
Timed reCAPTCHA and privacy follow-up
For long and multipage forms, use the Gravity Forms reCAPTCHA token expiry test to separate lifecycle failures from low scores. For stored spam records, continue with the spam entry personal data retention audit to map fields, files, logs, integrations, and backups.
Accessibility, retention, privacy, and fieldless reCAPTCHA errors
For slow or assistive journeys, run the reCAPTCHA long-form accessibility recovery test. Monitor cleanup with the spam retention cron monitor, verify privacy requests with the spam-entry export coverage test, and diagnose a form-level error with the reCAPTCHA no-field-errors guide.
Helpful references