Gravity Forms documents the honeypot reason that gform_submission_speeds is empty or invalid. That differs from a valid timing payload that is simply faster than the configured threshold. Cached JavaScript, multipage transitions, AJAX, custom embeds, autofill, accessibility tools, and programmatic submits can each change the evidence.
Use this when legitimate entries are marked Spam with the empty or invalid submission-speed reason, or when a speed threshold change is being considered without reliable timing data.
Quick answer
Preserve the entry note and Submission Speed metabox, then compare the timing payload across uncached, cached, AJAX, multipage, autofill, keyboard, mobile, and programmatic paths. Read the Gravity Forms core log and isolate script optimization before changing thresholds. Empty or malformed data needs a rendering fix, not a looser speed value.
What to check first
- Record form ID, page count, AJAX state, threshold mode, entry note, Submission Speed values, browser, cache result, and how the user completed the form.
- Capture the gform_submission_speeds field and relevant script requests for a normal paced submit, a fast autofill submit, a multipage submit, and an invalid control.
- Compare cached and uncached pages plus logged-in and anonymous sessions to find timing scripts that are missing, delayed, combined, or stale.
- Review core logs for the parsed timing array, threshold calculation, minimum required count, bypass paths, and final honeypot decision.
- Fix the data path first, then tune threshold only with a measured distribution of valid submissions and a retained spam control.
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 |
|---|
| Preserve the note and timings | Record form ID, page count, AJAX state, threshold mode, entry note, Submission Speed values, browser, cache result, and how the user completed the form. | All supported browser and form paths produce a valid timing payload. |
| Capture representative paths | Capture the gform_submission_speeds field and relevant script requests for a normal paced submit, a fast autofill submit, a multipage submit, and an invalid control. | Legitimate autofill and accessibility cases remain Active. |
| Inspect scripts and logs | Compare cached and uncached pages plus logged-in and anonymous sessions to find timing scripts that are missing, delayed, combined, or stale. | A deliberately malformed or automated control still reaches Spam. |
| Repair invalid data | Review core logs for the parsed timing array, threshold calculation, minimum required count, bypass paths, and final honeypot decision. | The chosen threshold and minimum count are documented with sample evidence. |
Why this usually happens
- JavaScript optimization can delay initialization until after the user reaches Submit.
- Multipage and AJAX forms can produce different timing segments than a one-page control.
- Password managers and autofill can complete a valid form much faster than manual typing.
- A headless or API integration may not use the browser timing field at all and needs its own validation design.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
form_id: 18
ajax: true
pages: 3
submission_speeds_present: true
segments_ms: [6400, 9200, 3100]
threshold_ms: 1500
minimum_required: 2
spam_reason: none
control_invalid_payload: 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.
- Preserve the note and timings
- Capture representative paths
- Inspect scripts and logs
- Repair invalid data
- Tune only with measured evidence
Decision rule
If the field is empty or invalid, repair the script or submission integration. If the field is valid and genuine users fail the speed threshold, adjust threshold and mode from observed data while retaining a malicious fast-submit control.
What to tell the client or owner
Share form settings, threshold mode, entry note, timing values, browser and input method, cache and script results, core-log decision, invalid control, final threshold, and monitoring date.
Production verification checklist
- All supported browser and form paths produce a valid timing payload.
- Legitimate autofill and accessibility cases remain Active.
- A deliberately malformed or automated control still reaches Spam.
- The chosen threshold and minimum count are documented with sample evidence.
Mistakes to avoid
- Do not treat empty timing data as proof that a human submitted too quickly.
- Do not lower the threshold before checking script loading.
- Do not test only a slow manual desktop entry.
- Do not retain raw personal form values when timing metadata is enough.
Questions teams ask during testing
What is the Submission Speed metabox?
Gravity Forms can show saved speed data on the Entry Detail sidebar. It helps explain how individual form segments compared with the configured threshold.
Can autofill cause a legitimate fast submission?
Yes. Autofill, password managers, accessibility tools, and returning users can complete fields quickly. Test those paths before choosing a threshold.
When HandL WP should help
HandL WP can reproduce the Gravity Forms timing failure, trace optimization and AJAX behavior, protect valid accessibility and autofill paths, and keep an effective spam threshold.
If this is active on a production site, fix Gravity Forms submission-speed spam.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Correlate AJAX, CAPTCHA, validation, and confirmation evidence
When the visible symptom is a spinner or generic error, use the Gravity Forms AJAX CAPTCHA and validation log workflow to identify the first divergent browser, WAF, PHP, validation, spam, or confirmation layer.
Helpful references