Release Incident Playbook

Form submission silently fails: symptoms, cause, and the test that catches it

A form submits without error but data is never stored after a validation or endpoint change.

Form submission silently fails is documented by 2 accepted public reports from 2 organisations, 1 of them published in the last 5 years.

  • Likelihood: not published (1 public report in 5 years)
  • Impact: high (2 of 2 reports: data)

2 public reports · verified 2026-10-21

Symptoms

User-visible

  • Visitors who submitted the contact or estimate form still got a thank-you page while their submissions were discarded.[1]
  • Forms whose fields were changed between 9 and 14 October 2020 stopped collecting visitor data from the added or renamed fields.[2]

Monitoring-visible

  • The form dashboard showed a gap in verified submissions while email notifications for the same sign-ups had still arrived.[2]
  • The form capture store held no new submissions from the contact or estimate forms after the release.[1]

Root causes

  1. stage: code Both forms posted to /contact-success and /estimate-success, and the form capture service records a submission only when the POST lands on a static file. The static success pages had been removed to add noindex, so those addresses resolved to framework pages that answered the POST first.[1]
  2. stage: code A code deploy on the hosting platform on 9 October 2020 stopped the form handling service from processing updates to forms whose fields were added, removed or renamed.[2]
  3. stage: code The success response shown to the visitor did not depend on a stored record, so the form reported success whether or not the submission was saved. by design analysis

Public examples

  1. [1]Hose Water, 2026-09-30. After static success pages were removed from a Next.js site hosted on Netlify, the contact and estimate form success addresses resolved to Next.js pages, so Next.js answered the POST, Netlify never captured the submissions and visitors still saw a thank-you page. primary Fix: restore form submission delivery
  2. [2]Netlify, 2020-10-14. A Netlify code deploy on 9 October 2020 stopped the form handling service from processing updates to forms whose fields were added, removed or renamed, so visitor data submitted in those changed fields was not saved until 14 October 2020 and could not be restored. primary Potential Missing data from form submissions in Oct 9-14 2020

Test classes that catch it

Test classStageLimitationBasis
End-to-end testspre-deployAn end-to-end test that asserts the thank-you page passes here, because visitors still got that page, so the test catches the fault only when it reads the stored submission.by design analysis
Synthetic monitoringpost-deployA production probe that submits an unchanged form stays green, because the platform fault dropped only data in fields that had been added, removed or renamed.by design analysis

Risk

  • Likelihood: not published (1 public report in 5 years)
  • Impact: high (2 of 2 reports: data)
Counts behind the grades
Accepted public reports2
Published in the last 5 years1
Impact stated: data2

How the grades are computed

Pre-release checklist

  • PR-01
  • PR-02
  • PR-03
  • PR-04
  • PR-05
  • PR-06
  • PR-07

First 30 minutes

  • FM-01
  • FM-02
  • FM-03
  • FM-04
  • FM-05
  • FM-06
  • FM-07

Download the checklist

What catches this: catalogue entries

Listed because their own documentation or site names end-to-end tests, synthetic monitoring on the verification date. Alphabetical. Not a recommendation.

Tools whose documentation names these test classes

Providers whose site names these test classes

Only on this page

Form submission silently fails kept a success signal in place in each report. In report [1], visitors still got a thank-you page while the framework page answered the POST and the submission was discarded. In report [2], email notifications for sign-ups still arrived while the form dashboard showed a gap in verified submissions.

The data in report [2] was not saved from 9 to 14 October 2020 and could not be restored. The repair in report [1] was verified by checking the stored record: a separate deployment of the branch captured submissions from both forms and delivered the notification email. A test for this incident has to assert on the stored submission and on each changed field, because visitors still saw a thank-you page in report [1] and notification emails still arrived in report [2].

Questions

What causes form submission silently fails?

In report [1], static success pages were removed, so a framework page answered the form POST before the capture service saw it. In report [2], a platform code deploy stopped processing updates to forms with added, removed or renamed fields.

What are the symptoms of form submission silently fails?

Visitors still got a thank-you page while their submissions were discarded [1]. The form dashboard showed a gap in verified submissions while email notifications still arrived [2].

Why did tests not catch form submission silently fails?

Neither report names a test class. In report [1], visitors still got a thank-you page, so a test that checks only that page passes. In report [2], notification emails still arrived while changed-field data went unsaved, so PR-03 checks the stored value of each changed field.

Which public reports document form submission silently fails?

Two primary reports document it, published on 2026-09-30 [1] and 2020-10-14 [2]. Both classify the impact as data.

Should a team roll back or fix forward when form submission silently fails happens?

Report [1] fixed forward by restoring the static success pages and their two rewrites, now with noindex. The platform in report [2] retroactively processed form updates for current production deploys. FM-05 covers this decision.

Release Incident Playbook (2026). Form submission silently fails: symptoms, cause, and the test that catches it, content version 1.0.0. https://releasefailures.com/incidents/form-submission-silently-fails/. Accessed 2026-10-21.