Why HTTP 200 is not enough

Most uptime monitors ask one question: does the URL return a successful status code? That catches outages, but plenty of real failures look perfectly healthy from the outside.

Failures a 200 hides

• A product page loads but the price is missing.
• The checkout button renders, but the payment script failed to load.
• An API returns 200 with an empty list because a database query silently broke.
• A deployment replaced the real page with a maintenance placeholder that still answers 200.

What to check instead

Test the outcome, not the response. For a shop that means: can I find a product, add it to the cart and reach payment? For an API: does the response contain the fields clients rely on, with sensible values?

Where custom checks fit

Standard monitors are great for reachability and certificate expiry. Custom checks fill the gap: small pieces of logic that know what “working” means for your product — a price in the right range, a cart that adds up, a webhook that arrives within a minute.

That is the idea behind custom checks on Upzilla, which we are preparing now.