What happened
This store’s largest orders start with a quote request form. Customers list what a job needs, the sales team prices it, and about a third of quotes become orders. On a weekday morning the form usually receives about thirteen requests an hour.
At 07:54, during the agency’s monthly maintenance, the forms plugin was updated from 3.4 to 3.5. The new version loaded its script differently, and on the live site, combined with the site’s caching and CDN, the script failed in the browser. From 08:00, pressing submit did nothing.
Because the requests never reached the server, nothing on the server reported a problem: no PHP errors, no failed submissions in the forms plugin, and orders through the cart carried on as normal. The maintenance check passed because it did not include the quote form.
Operanse does not see the browser error itself. What it saw was that the submissions it expected were not arriving. At 08:45, after forty-five minutes with none, it added a warning to the daily summary. At 09:30, after ninety minutes and about twenty missing requests, it sent an alert. This store had chosen to be alerted only for critical incidents.
The morning, replayed. The quote form is the third row: it goes empty at 08:00, and the dashed markers show the submissions expected from past activity.
The form that stopped. A quote form that went quiet at 08:00 with no error anywhere and every other lane healthy; the forms plugin update at 07:54 was the only recorded change. Caught at 08:45, messaged at 09:30 (with only critical incident alerts on).
- 07:54Change recorded: Forms plugin 3.4 → 3.5 · by an administrator (wp-admin)
- 08:45Quote form · Warning: no submissions for 45 minutes, against about 10 normally · added to the daily digest, no alert sent
- 09:30Quote form · Critical: no submission for 90 minutes on a form that usually has about 20 by now · alert sent · message sent
No quote request has arrived since 08:00; about 20 would have by now. Orders, payments and errors are inside their bands; the forms plugin update at 07:54 is the only recorded change. - 09:48Change recorded: Forms plugin rolled back to 3.4 · by an administrator (wp-admin)
- 10:04Quote form · Resolved after 79 minutes: 5 submissions since the rollback, back to normal
What happened next
The alert said no quote request had arrived since 08:00, that about twenty would normally have arrived by then, that orders, payments and errors were all normal, and that the forms plugin update at 07:54 was the only recorded change.
The developer opened the quote page with the browser console open, found the script error, rolled the plugin back at 09:48 and cleared the CDN. Requests resumed at 09:51 and the incident closed at 10:04.
There is no dollar estimate for this one, because a quote request is not yet an order. For the sales team, though, twenty missing requests, a third of which usually become jobs, was a real loss. Two customers phoned to ask whether the form was broken; others may simply have gone elsewhere.
How to prevent it
- Include every important form in the post-release check: submit it end to end on the live site after clearing the CDN, and confirm the test request arrived.
- Run staging with the same caching and script optimisation as the live site. This failure came from the combination, not from the plugin alone.
- Mark the quote form as important, so a quiet spell on it is flagged sooner than one on a newsletter sign-up.
- Add browser-side error tracking to the quote and checkout pages, so script errors on customers’ screens are reported too.
Related tools and examples
- Read a WordPress PHP error log: useful to rule the server out. A form that fails in the browser, as this one did, leaves nothing there, and that absence is itself a clue.
- See how a payment gateway update stopped orders: the same pattern of a routine update failing only on the live store, at checkout instead of a form.
How Operanse catches it
Each form is monitored separately, against what it usually receives at that hour. Submissions rejected as spam or invalid are counted separately, so they are never mistaken for real submissions or for failures.
A form that fails in the browser can only be detected from the server by its silence, and that is what Operanse watches for. The chart shows the submissions expected during the outage, based on past activity.
Operanse compares each store’s activity with its own history and groups related anomalies into incidents. Playback, the replay above, is on Monitor and Insight; Insight adds server monitoring and an AI review of the likely cause, with its evidence. How Operanse monitors a WooCommerce store.