Your booking link works. Test what happens when it fails.
Twenty-six public booking links, twenty-six HTTP 200s, nine dead pages. A four-joint test for the booking chain that status-code monitoring cannot see.
A booking link that returns HTTP 200 is not a booking link that works. I tested that claim on 10 November and it held with uncomfortable precision.
The test was small and reproducible. I collected 26 public booking links from live search results — sixteen Calendly paths, ten Cal.com paths — and requested each one exactly the way a link checker would. Twenty-six responses, twenty-six HTTP 200s, zero redirects, zero errors. Every single link passed.
Then I opened the same 26 URLs in a real browser and let the page finish rendering. Seventeen produced a calendar with selectable times. The other nine produced one line of text: "This Calendly URL is not valid."
Nine dead booking pages, and the only signal a status-code check could have caught was a success.
What the status code actually measures
The dead pages and the live ones are indistinguishable at the HTTP layer. I compared response headers on both: same 200, same cache-control: max-age=0, private, must-revalidate, same content type, same x-booking-bff-response: true on the way back. The body is a JavaScript shell — roughly 1.1 KB of HTML whose only content is an empty root element and a script tag. The page becomes a booking page, or an error, after the bundle runs.
That ordering is the whole problem. The status code is written and sent before anything that decides whether the booking is possible. A bot, a crawler, an uptime monitor and a link checker all stop at the status code, so all four report the same thing: fine.
The platforms even have a clean 404. When I requested paths that could never resolve — invented slugs, a fabricated invitee link — Calendly answered 404 with a 216 KB error page, Cal.com answered 404 with its own not-found page, and a non-existent Google appointment short link answered 404 "Dynamic Link Not Found". The plumbing works. It just does not fire for the failure that matters, where a link resolves to something that is no longer serving.
Worth stating plainly: search results are a lagging index, so a sample pulled from them over-represents stale links. The nine dead pages here are not a base rate for the internet. They are proof that a link people still find is not a link that still books, and that your monitoring will not tell you which is which.
The four joints of a booking chain
A booking is not a page. It is a chain of four joints, and it fails at whichever joint nobody instrumented.
| Joint | What the booker sees when it breaks | What you see | The check that catches it |
|---|---|---|---|
| 1. Public link resolves to an active event type | An error message, or a page that loads forever | Nothing. Status 200, latency normal | Render the page and assert that a time slot exists |
| 2. Slot is real availability | A time is offered, then refused at submit | A conflict, or nothing | Double-submit the same slot and assert one booking wins, one is refused cleanly |
| 3. Booking write reaches the calendar and the CRM | "You're booked" — with no record behind it | The meeting on the calendar, the opportunity missing | Assert a record exists in the CRM with the synthetic booking's tag |
| 4. Confirmation is delivered | No email, wrong time zone, dead reschedule link | Nothing. The booking looks successful | Assert delivery, time zone and reschedule link on the confirmation |
Joint 1 is the one everyone checks, and the table above shows why that is not enough: it is also the joint with the loudest failure. A broken public link produces support messages, so it gets fixed. Joints 3 and 4 produce no messages at all, because the customer believes they booked and the calendar agrees with them.
That is the specific, expensive version of this failure. The appointment happens. The record does not. No pipeline stage is created, no follow-up sequence starts, and the person who showed up on Tuesday exists in the calendar and nowhere in the CRM. When the quarter is reviewed, it reads as a demand problem rather than a handoff problem.
Why joints 3 and 4 stay broken
Both are asynchronous, and both are somebody else's success criterion.
On the booking side, webhooks exist for exactly these events. Calendly's documentation covers invitee-created, invitee-cancelled and routing-form submissions, and adds a detail that matters for anyone planning a backfill: webhooks are not triggered by past events. Cal.com exposes a wider set — BOOKING_CREATED, BOOKING_CANCELLED, BOOKING_RESCHEDULED, BOOKING_REJECTED, MEETING_ENDED — which is useful, and also more surface to fail.
Delivery is where it gets quiet. A webhook that returns 500 three times and then stops retrying looks, from the CRM, exactly like a week with no bookings. Nothing in the pipeline records the absence. This is the same shape of failure as any other automation that dies between two systems: the work upstream continues, the gap downstream is silent, and the first person to notice is the customer.
Confirmation email has an extra trap. The booking is successful, the calendar event is correct, and the confirmation renders the invitee's time zone — which may not be the time zone the booking was created in. A customer who books from a hotel wifi in another country gets a correct booking and an incorrect hour in their head. Nobody files a bug for that; they just arrive at the wrong time.
The test that takes one booking a week
You do not need a monitoring vendor to cover all four joints. You need one synthetic booking and three assertions.
- One tagged booking, once a week. Use a real slot on a real event type, with an address you control that carries a unique tag (for example a plus-address per week). Never use a special hidden event type: you want the path a customer takes, including its buffers, its minimum notice and its payment step if it has one.
- Assert the record, not the confirmation screen. The success page is the least reliable evidence in the chain. Check that the calendar event exists, then check that a record exists in the CRM with the tag. If the CRM record is missing, you have found a joint 3 failure before a customer did.
- Dead-letter the webhook. If the booking event has not produced a success response within ten minutes, alert. Not "retry silently" — alert. A dead letter queue nobody reads is a nicer-looking version of the same silence.
- Assert the confirmation. Delivery, the displayed time zone, and a reschedule link that actually resolves. Three assertions, one message.
- Keep the log. A green week is evidence. Without the log, a good week and an unnoticed outage look the same in the review.
Once that is running on your own site, repeat it for every other public entry point: the Business Profile, the directory listings, the email signature, the chatbot, the ad landing page. Google is now attaching booking links to Business Profiles on its own, and Search Engine Roundtable documented at least one instance returning a 500 error on click. You do not control that link, you cannot monitor it from your own infrastructure, and it is pointing at your calendar anyway.
Fix the chain before adding a channel
The instinct when bookings are soft is to add another surface — a chat widget, a second booking tool, a WhatsApp flow. In client work the more common finding is that the chain already in place leaks in the middle, and the new channel inherits the same four joints plus one more.
So the order that holds up: inventory every public booking entry point and give each one an owner; instrument the four joints with a synthetic booking; fix what the test finds; only then add a channel. Our CRM implementation engagements usually start at joint 3 for exactly this reason — the appointment exists, the pipeline does not, and nobody has ever traced one booking from a public link to a record with a stage.
If you want the wider picture of how booking demand is shifting toward AI-mediated surfaces, the booking eligibility rules behind AI Mode are the adjacent problem: what an assistant can see and act on is decided before anyone clicks. And if the failure you are chasing is in a different automation entirely, the heartbeat pattern for silent failures covers the general case. For the architectural version of the same chain — availability checks, CRM writes and confirmations in one flow — see AI agents for appointment scheduling.
If you want the chain on your own site tested end to end, send us the public booking URL and we will run it through all four joints.
The rule
A status code describes the transport, not the transaction. Booking links are the clearest case I know where those two diverge completely: 26 successes on the wire, nine of them dead on the screen.
Test what the customer experiences, not what the server returns. The gap between those two answers is where the appointments are.
Frequently Asked Questions
How do I check whether my booking link still works?
Open it in a private window on a phone, pick a slot and complete a real booking under a tagged test address. Then confirm three separate things: the event appears on the calendar, a record appears in the CRM with that tag, and the confirmation email arrives with the right time zone and a working reschedule link. A 200 response proves none of those; it only proves a server answered.
Why does a dead booking link still return HTTP 200?
Because the booking page is a JavaScript shell. The server returns the same 200, the same headers and a roughly 1 KB HTML document with an empty root element, then the bundle loads and decides what to show. When the link no longer resolves to an active event type, the error message appears after that render, long after the status code has been sent. That is why uptime monitors, link checkers and crawlers report a dead booking page as healthy.
What is the cheapest way to monitor a booking chain?
Three checks, once a week: one synthetic booking on a tagged address that must produce a calendar event, a CRM record and a confirmation message; a dead-letter alert if the booking webhook has not returned a success response within ten minutes; and one assertion on the confirmation's time zone and reschedule link. That covers the four places a booking chain breaks without needing a monitoring vendor.
