Uptime monitoring from outside your own infrastructure that alerts you the minute your site goes down — upordown.online

This is a hypothetical case study. The shop, the numbers and the timeline are invented, but every piece of it is something that happens to real checkouts.

The setup

A mid-sized online shop sells outdoor gear. Its monitoring was better than most:

  • An uptime check on the homepage every minute.
  • A check on the /checkout page that looked for the text "Pay now".
  • A synthetic test every 15 minutes that added a product to the cart and completed payment with the payment provider's test card in the staging environment.
  • An alert if the order rate dropped below 30% of the same hour last week.

On a Tuesday afternoon, a developer shipped a change to the checkout page: the payment form moved into a modal, to make the page feel faster on mobile. Everything passed review. Every check stayed green.

What customers saw

When a customer's bank required Strong Customer Authentication (in Europe, most online card payments above a small amount; elsewhere, whenever the bank's fraud model asks for it), the payment provider needs to show a 3-D Secure challenge: a bank page, usually in an iframe or redirect, where the customer confirms the payment in their banking app.

The new modal closed itself when it lost focus. On mobile, switching to the banking app to approve the payment counted as losing focus. The customer approved in the app, came back to the browser, and found the checkout page with the modal closed and no confirmation. The payment intent sat in requires_action until it expired. Some customers tried again; most left.

Customers whose cards didn't trigger a challenge paid normally. That was most of them outside Europe, and a minority inside it.

This is why an outside check of the real checkout path matters. upordown.online monitors the URL that takes payment, not just a health endpoint that stays green.

Why every check missed it

The uptime checks saw a page that loaded. The homepage and the checkout page both returned 200 with the expected text. Nothing was down.

The synthetic test used a test card that never asks for 3-D Secure. Payment providers publish separate test cards for "succeeds", "requires authentication" and "declined". The test used the first one, so it tested exactly the path that still worked.

The order-rate alert had a threshold built for outages. Orders dropped about 22% over the following days. That's alarming once you see it, but it was well above the "30% of last week" floor, which was designed to catch a full checkout outage. A weekday sale the week before also made the comparison noisier.

Nobody owned the requires_action count. The payment provider's dashboard showed a growing pile of payment intents stuck in requires_action. Nobody looked at that dashboard unless something was already wrong.

The problem was found on Saturday, when a customer emailed a screenshot from their banking app showing a payment they'd approved for an order that didn't exist.

The fix

The immediate fix was small: the modal no longer closes on blur, and the checkout page, on load, checks for any payment intent in the session that's waiting for action and resumes it. The provider's client library already supported resuming; it just needed to be called.

The monitoring fixes mattered more:

1. Test every card outcome, not just success

The synthetic checkout now runs three times per cycle: with the success card, with the "authentication required" card (it completes the test challenge), and with a decline card (it checks the error message is shown). A checkout that only tests the happy path only protects the happy path.

2. Alert on payment states, not just order counts

The shop added a scheduled query against the provider's API: how many payment intents are in requires_action or requires_payment_method for longer than 30 minutes, compared with the same window last week. A ratio that doubles is a page. This metric would have fired within two hours on Tuesday.

3. Split the order-rate alert by segment

Overall order rate hid a collapse in one segment. Splitting by card country and payment method showed it immediately: European card payments were down by more than half while everything else was normal. A drop in a single segment is a much stronger signal than a modest drop overall.

4. Test the flow on a real phone

Desktop browsers don't lose focus when you open a banking app. The team added a manual pre-release check on one iOS and one Android device for any change to the checkout UI. It's ten minutes per release and it's the only test that reproduces the actual bug.

What I'd take from it

  • "Up" is not the same as "working". A 200 with the right text proves the page renders. It proves nothing about whether a payment completes.
  • Your test data defines what you're monitoring. If the synthetic test uses one card, you're monitoring one card.
  • Look at stuck states. Anything that can be "pending", "requires action" or "processing" should have an age alert.
  • Segment before you average. An average across all customers is where partial outages go to hide.

External checks like the ones upordown.online runs are the first layer here: they catch the checkout page going down or losing its "Pay now" button. The second layer, the one this shop was missing, is checking the outcomes behind the page.

Related reading

Has a checkout of yours ever failed for only one kind of customer? How long did it take to notice, and what finally gave it away?