What happens when your form endpoint goes down

Form backends are chosen on price, integrations and how quickly you can paste a URL into a page. Almost nobody asks the question that decides whether the service is any good: what happens to my submission when something breaks?

It is understandable, because the answer is invisible while everything works. A form that quietly loses one submission a month looks identical to one that has never lost anything.

The difference only shows up in a comparison nobody runs, between the number of people who pressed submit and the number of rows that exist. Since almost no site can produce the first number, the failure never surfaces.

So it is worth reasoning about the design instead, because the design is visible before the incident.

To the visitor these look identical, and to your data they could not be more different.

The first is a failure before acceptance: the endpoint is unreachable, or it returns an error before the submission is stored anywhere. The data is gone. The only copy was in the browser and the browser has moved on.

The second is a failure after acceptance but before delivery: the submission was stored, but the write to your spreadsheet failed. Nothing is lost, and the fix is retrying.

The third is a failure in the response: everything worked, but the confirmation never reached the browser. Nothing is lost, but the visitor believes it failed, and will probably submit again.

The single most important property of a form pipeline is that acceptance and delivery are separate steps.

When they are the same step, every downstream dependency becomes a single point of failure for your lead capture. If the spreadsheet API is slow, your form is slow. If it is down, your form is down, and the submission that was in flight is gone.

When they are separate, the endpoint stores the submission and returns immediately, and a separate process takes responsibility for getting it to its destination. A destination outage becomes a queue that drains later rather than a set of lost enquiries.

This is the same reasoning behind every durable queue in software, applied to the least glamorous part of a website.

Accept fast, on the smallest possible amount of work. Store before doing anything clever, including spam scoring, notification and delivery.

Then fail loudly to yourself and quietly to the visitor. The person who filled in the form should see a confirmation because their part genuinely succeeded. You should see a queued item, a failed attempt, and eventually an alert if it stays failed.

That asymmetry is deliberate and worth stating, because the instinct runs the other way. Showing the visitor a technical failure they cannot act on produces a resubmission, an abandoned enquiry, or both. The only person who can do anything about a delivery problem is you.

And retry with increasing gaps rather than immediately. A destination that just failed is often about to fail again, and hammering it is how a small outage becomes a rate-limit ban.

The final property is that failure is visible after the fact. A pipeline that recovered silently is fine; one that cannot tell you it ever had a problem is not.

Some of this is your page rather than your backend, and it is worth doing because it is cheap.

Do not clear the form on submit until you have a success response. A page that empties itself optimistically and then shows an error has destroyed the visitor's work, and they will not retype it.

Do not disable the submit button permanently on the first click. Disable it briefly to prevent an accidental double, then restore it if the response indicates failure.

And give a real error message when the request fails. Something went wrong is the message that loses the lead; please try again, or email us at this address is the one that saves it.

Hosted form services publish uptime figures, and those figures are worth reading with the accept-then-deliver distinction in mind.

Uptime for the ingest endpoint is the number that matters for data loss, because that is the window where submissions can disappear. Uptime for the delivery worker matters for latency: if it is down for an hour, your rows arrive an hour late, and nothing is lost.

A vendor that reports one combined figure is telling you less than it appears. The useful question is which component the number describes, and what the retry behaviour is for the other one.

A static site has no server of its own, which makes the form endpoint the only dynamic part of the page and therefore the entire failure surface.

That concentration is usually a benefit: one dependency to reason about instead of a stack. But it also means an endpoint failure is a total failure of the only interactive feature you have, with no application layer of yours to catch it.

The practical mitigation is unglamorous. Publish a visible email address somewhere on the contact page. When the form fails, the visitor still has a route, and a small number of people will use it and tell you something is broken.

You can learn most of what you need in ten minutes with browser developer tools.

Open the network panel, set it to offline, and submit the form. Watch what the page does. Does it show a useful error, keep the entered data, and allow a retry? Or does it hang, clear itself, or claim success?

Then try a slow connection rather than an offline one, because the timeout path is different from the failure path and is more often mishandled. A form that waits thirty seconds with no feedback is functionally broken even though nothing failed.

Neither test touches your backend, and both find real problems on most sites.

One number tells you whether any of this is working: submissions accepted against rows delivered, over a period.

If those two agree, your pipeline is healthy regardless of what happened in between. If they diverge, you have a delivery problem you can quantify rather than suspect.

This is only possible when acceptance is recorded separately from delivery, which brings the argument back to the same place. The split is not an implementation detail, it is the thing that makes the system measurable at all.

It is worth checking that the number is available to you rather than only to the vendor. A log you can read turns the comparison into something you can run on a Monday morning; a status page you cannot query turns it into a support ticket.

Ask whether submissions are stored before delivery is attempted. Ask what happens on a destination failure, and whether retries are automatic. Ask whether you can see failed deliveries, and whether you are told about them.

Those three questions separate a durable pipeline from a proxy that forwards and hopes. Our own answers are in how it works, and the shape is deliberate: accept, screen, store, then deliver with retries and a visible log.

A form that has never lost a lead is not a form that never fails. It is one that was designed for the afternoon when something does.

How would I even know if I lost a submission?

Does a retry risk creating duplicate rows?

Should the form show an error if delivery fails later?

What is a reasonable retry schedule?

Is an outage at my spreadsheet provider a problem?

What about submissions in flight during a deploy?

Do I need a fallback endpoint?

How do I test failure safely?