Your Website Is Online — But Does the Checkout Work?
Why uptime checks and error tracking miss silent conversion failures, and how synthetic checkout tests expose lost revenue earlier.
A website can look healthy, load quickly, and still be broken exactly where revenue is created.
The homepage returns HTTP 200. Uptime monitoring says “online.” The error tracker shows nothing alarming. Meanwhile, real prospects click “Continue” in the checkout and see a blank page, an endless spinner, or no response at all.
This is not an exotic edge case. It is a common gap between technical uptime and working business functionality.
The dangerous myth: “Sentry would have told us”
Error tracking matters, but it is not omniscient. A checkout can fail without producing a neatly captured JavaScript exception:
- a database migration is missing only in production
- an API returns the wrong business result with a technically successful status
- a button remains disabled because of state logic
- a redirect ends on an empty or unreachable route
- a payment or authentication SDK gets stuck between states
- an error is caught but never logged meaningfully
- the frontend renders a generic blank state instead of throwing
An error tracker answers: “Which errors were captured?” It does not automatically answer: “Can a customer complete a purchase right now?”
What a checkout monitor must actually verify
A useful synthetic test does not merely open the checkout page. It follows the business-critical journey until there is a clear success signal.
Depending on the product, it should at least:
- open a real product or pricing page
- select an item or plan
- start checkout
- complete required fields
- verify consent and validation states
- observe the request to the backend or payment provider
- confirm a defined success page, confirmation, or expected test response
The final assertion is what matters. “The button was clicked” is not success. “The order confirmation is visible” or “the test transaction was created correctly” is success.
Playwright provides web-first assertions that wait for and verify an expected state. It can also retain traces, screenshots, and network activity, turning a failed check into useful diagnostic evidence rather than a vague alert.
Why CI testing alone is not enough
End-to-end tests before deployment are essential, but they only protect against failures that exist in the environment being tested.
Production failures often appear because of differences such as:
- missing or delayed database migrations
- different environment variables
- domain, cookie, or redirect configuration
- production data and real permissions
- network or DNS problems
- third-party configuration
- caching, CDN, or edge middleware
- feature flags with different values
A critical funnel therefore needs two layers:
Deployment gate: Run the checkout test against preview or staging and block release when it fails.
Production check: Run a safe synthetic journey against the real environment on a schedule and alert when the funnel can no longer be completed.
The production check must not create real charges or unwanted records. Practical options include sandbox payment methods, dedicated test products, test accounts, idempotent endpoints, or a controlled stop immediately before a real charge.
Five red flags for silent checkout failures
1. You monitor only the homepage
A reachable homepage says nothing about login, basket, forms, checkout, or confirmation.
2. Success means only “no exception was thrown”
A journey can fail at the business level while remaining technically exception-free.
3. Tests run only on developer machines
Local tests do not see production configuration or real deployments.
4. Failed tests produce no evidence
Without a trace, screenshot, browser console, and network data, investigation starts from zero.
5. Nobody owns the alert
An alert without an owner, priority, and response target is automated noise.
A pragmatic minimum standard
For a small SaaS product, shop, or booking platform, the setup does not need to be heavy:
- one Playwright test for the most important conversion path
- execution after every deployment
- an additional scheduled run against production
- an explicit assertion on business success
- trace and screenshot retention on failure
- notification to a channel that is actually watched
- documented test data and cleanup behavior
- a monthly check that the script still reflects the real user journey
Use retries carefully. They can absorb short-lived instability, but they can also hide a fragile checkout. A flow that succeeds only on the third attempt is not healthy. It is a warning.
What Website-Pflichtencheck would examine
A conversion and operations review should not stop at page availability. It should inspect the complete path from entry to confirmation:
- do buttons, validation, and state transitions work?
- do frontend, API, and database schema agree?
- are required migrations part of deployment?
- are business failures visible and understandable?
- do logs include useful context and correlation IDs?
- are critical journeys automated?
- are there production checks, not only CI tests?
- do alerts reach a responsible person?
- can a failure be reconstructed from traces and network evidence?
A checkout that remains broken for weeks is rarely just “a small bug.” It shows that monitoring was aimed at the infrastructure rather than the business outcome.
Uptime means the server responds. Availability means the customer reaches their goal. Protecting revenue, leads, and registrations requires monitoring that exact journey.