If your website enquiry form is not working, the fault can appear in several ways. The button may do nothing. The page may show an error. Or the request may be saved while its email alert never arrives. Each fault needs a different check.
Trace one agreed test request from the browser to the place your team reads it. Use your own details and mark it as a test. This guide gives business owners a safe way to find the broken step and hand useful evidence to a developer.
The short answer
- A success message is not proof that a lead was saved or an email arrived.
- Find the first missing record in the path before changing settings.
- Keep a working contact route visible while the fault is being repaired.
How this guide was made
We checked W3C guidance on form feedback, MDN's HTTP status reference and Resend's email documentation. The fault tree is our editorial troubleshooting method. No diagnosis of a specific website or live repair is claimed.
Sources checked .
Keep a working contact route available
If you have confirmed the form is broken, show a monitored phone number or email nearby. Explain the alternative in plain words. Do not leave a large Send button that silently loses messages.
Avoid deleting old submissions or switching off all spam protection to make a quick test pass. Those actions can create a second problem. Start by collecting evidence from one controlled test.
Record exactly what the visitor sees
Write the page address, date, time and time zone. Note the device and browser. Take a screenshot of the error after hiding private details. Copy the visible error text into your notes.
Try the same steps once on a second browser or device. If it fails only on a phone, say so. If it fails only with an attachment, include the file type and size, not the private document itself.
Use a short test message that you can find later, such as Form check for the website team. Do not repeat submissions rapidly. Repeated clicks can create duplicate requests or trigger a limit.
Use this illustrative fault tree
This worksheet separates the main stages. A result points to the next place to inspect, not a final cause. Your site may use different tools, but the same questions still help.
| Observed result | Next place to inspect | Useful evidence |
|---|---|---|
| Button does nothing | Field checks or page script | Screenshot and browser details |
| Visible error after Send | The form service | Error text and request time |
| Success message, no saved lead | Save step and success logic | Test marker and server records |
| Saved lead, no email | Email alert step | Lead reference and email logs |
| Email exists, team did not see it | Inbox rules and recipients | Address, folder and delivery record |
| Duplicate leads | Retries and repeated clicks | Matching timestamps and references |
Do not assume the inbox is the whole system
Some sites save a lead before sending an alert. Others rely only on email. Ask how yours works. The answer changes where you look and whether any requests can be recovered.
Check field rules and page feedback
Start with the visible fields. Is a required field hidden on a small screen? Does a phone rule reject a normal local number? Does an optional field behave as required? Can someone use the form with only a keyboard?
W3C advises clear success and error feedback. A field error should name the field and help the person correct it. A failed service should not tell the visitor that their valid details are wrong.
Keep any test of a service failure in a safe test environment when possible. Ask the developer to confirm that a failed save cannot trigger a success screen.
Source for this section: [1] W3C, user notifications for forms
Ask a developer to inspect the request
When a form sends data, the website usually makes a request to a service. A developer can inspect whether that request was sent, where it went and what response came back.
MDN groups HTTP responses into classes. Codes in the 400 range generally indicate a problem with the request or its access. Codes in the 500 range indicate a server problem. A code is a clue, not a full diagnosis.
For example, a permissions error needs a different check from a server outage. Ask for the exact response and matching server record. Do not paste access tokens, cookies or full customer details into a public support thread.
If the request succeeds, continue to the stored record. A successful response does not by itself prove that every later alert was sent.
Source for this section: [2] MDN, HTTP response status codes
Trace the email alert separately
Confirm which address should receive new enquiries. Look for an old staff address, a typo or a setting that changed during a site move. Check spam, filters and shared mailbox rules.
Ask which email service sends the alert. Resend, for example, provides email records and API logs for troubleshooting. Your provider may offer similar records. Search by the test time and recipient to see whether the send was attempted.
If there is no email record, inspect the step that creates the alert. If a record exists, read its status and error details. Follow the provider's guidance for that exact result.
Have the developer check the verified sending domain and allowed sender settings. Do not make random DNS changes. Keep the old values and understand the change before applying a fix.
Source for this section: [3] Resend, sending and managing emails
Give the repair owner a complete handoff
A useful handoff is short and factual. Say which path fails, what you expected and what happened. Include the page, test time, browser, visible response and whether a lead or email record exists.
Ask the repair owner to state the cause, the change made and the check that proves it. A reply saying fixed is less useful than a record showing the same request now arrives correctly.
- Exact page and steps to reproduce.
- Test date, time and time zone.
- Visible error or success message.
- Saved lead reference, if one exists.
- Email status, if available.
- Person who will confirm receipt.
Verify the repair and agree future checks
Repeat the same agreed test on the affected device. Confirm the form response, saved lead and alert. Check that one submission creates one intended request.
Then try a missing required field to confirm the error message still works. If the form accepts uploads, test a permitted sample file and an unsupported type in a safe setting.
Agree a light check after changes to the form, domain or email service. Decide who receives failure alerts and who can cover their absence. Keep the fallback contact route current even after the form is repaired.
Common questions
Why does my form say success but send no email?
The page may confirm too early, or the request may be saved while the alert fails. Check the saved lead first, then the email provider's records for the same test.
Should I turn off spam protection?
Do not remove it as a first step. Inspect its logs or test settings with the developer. If a rule blocks valid visitors, adjust the specific rule and verify the result.
Can missing enquiries be recovered?
Sometimes. Check stored submissions and delivery records. If the site never saved or sent a request, there may be nothing to recover. Do not promise recovery before checking.
Sources and further reading
Numbered links beside each section point to the source used there. Our examples and checklists are guidance from SnapRebuild. They are not claims of test results. Product details can change.
SnapRebuild sells a website building service. These guides are published under our editorial team name and use AI for research and writing. This is not a claim of independent expert review. Read how we make and update our content. Found an error? Tell us.
Ready for a fresh start?
Bring your website or your business idea. Explore a SnapRebuild preview and decide what comes next.
Try your free preview