The site is up and the booking form still is not working

An uptime monitor asks a website one question: did the server answer? It sends a request every minute or so, gets back an HTTP 200 and a page of HTML, and concludes that everything is fine. For most of the history of the web that was a reasonable approximation, because a page that arrived was a page that worked.

It is not a reasonable approximation for a booking form. A booking widget is almost never in the HTML the server sends. It arrives afterwards, assembled in the browser by JavaScript that fetches availability from somewhere else. Every part of that can fail while the original request keeps returning a perfectly healthy 200.

The four ways a booking form fails on a page that loads

1. The script that mounts the widget never runs

A single JavaScript error earlier on the page stops execution before the scheduler is initialised. The button is still rendered, because it is part of the theme, so the page looks untouched. Clicking it does nothing at all. This is the most common version, and the hardest to notice, because the failure is silent by design: browsers do not display JavaScript errors to visitors.

2. The widget mounts and its data does not arrive

The calendar opens and shows no available times. To a visitor that is indistinguishable from a business with no availability, so they leave without contacting anyone. The request behind it failed, or returned an empty result because of an expired key, a rate limit, or a change at the booking provider.

3. An update moved something

A theme or plugin update changes a class name, a layout or the order of the steps. The flow now ends one click earlier than it used to. Everything before that point still works perfectly, which is exactly why nobody spots it. The site does not look broken, it looks slightly different.

4. The last request fails after every visible step succeeded

The visitor fills in their details, sees a confirmation, and no booking is recorded. This is the worst one, because the customer believes they have an appointment and will turn up expecting to be expected.

Why nobody reports it

The people who discover a broken booking form are the people who wanted to book, and they almost never tell anyone. They assume it is their browser, or their phone, or that the business is full, and they go to whoever is next in the search results. There is no error message, no support ticket and no bounce email. The first signal is a quiet month, weeks later, and by then nobody connects it to a plugin update.

What to check instead of the status code

The only reliable test is to do what a customer does, in a real browser, on a schedule. Concretely:

• Open the page the booking starts from, and confirm the trigger is present.
• Click it, and wait for the scheduler to actually appear rather than assuming the click worked.
• Confirm the calendar is offering times, not just that it rendered.
• Choose one, fill in the details, and get to the confirmation step.
• Watch the network requests the page makes along the way, so a step that looks right on screen and failed underneath still counts as a failure.

Doing this by hand once after a deploy is worth a great deal. The problem is that theme updates, plugin updates and changes at the booking provider do not happen on the day you deploy. They happen on a Tuesday, to a site nobody has touched since March.

Doing it on a schedule

This is what JourneyPing does: booking form monitoring that drives the real flow in a browser every few minutes, stops before it would create a real appointment, and tells you which step failed and what the page looked like when it did. Uptime checks still run every minute alongside it, because knowing the server is down is still worth knowing. It is just not the same question.

Whether you use a tool for it or write your own script, the shift that matters is the same: stop asking whether the page arrived, and start asking whether a customer could get to the end.