Debugging deliveries and retries
Diagnose why a stored lead has not reached an email, webhook or integration.
Start with the lead
Step 1: Confirm intake
Find the lead in the form Submissions page. Confirm workspace, test/production mode, form filters and whether the submission was accepted.
Step 2: Check quarantine
Suspected spam may be stored but not delivered. Review its reason before releasing it. Rejected requests are not accepted leads.
Step 3: Identify the destination
Inspect the Deliveries page or form delivery history. Check destination status, attempt count and recorded HTTP status.
Step 4: Fix, then replay if eligible
Correct endpoint connectivity, credentials, permissions, URL mapping or provider settings. Use replay only when the plan and destination state permit it.
Common result types
- Delivered or provider-accepted: the configured receiver or transport accepted the attempt, not necessarily that a human read it.
- Retryable failure: timeout, network failure, HTTP 408, 429 or 5xx; bounded retries may follow.
- Permanent failure: most ordinary 4xx responses, invalid URL or unsafe destination; fix configuration before trying again.
- Suppressed or held: a plan, anti-abuse, quota or spam rule intentionally prevented dispatch.
Investigate safely
Record the approximate UTC time, form, masked destination and HTTP status before contacting support. Do not send raw tokens, webhook signing secrets or full private lead payloads in public conversations.
Open general troubleshooting