A 200 OK is not a completed checkout.

Downtime on a sale day is revenue you do not get back, and the traffic spike is exactly the moment everything has to hold. Perstat checks your checkout and payment surfaces for the content that proves they rendered, watches the certificate and the domain whose lapse would take the whole store offline, and confirms a failure across more than one continent before it wakes anyone. Availability and its evidence, not analytics.

The stake is the checkout, not the homepage

An uptime tool that only checks whether your homepage returns 200 is watching the wrong thing. On a sale day the homepage can be fine while the checkout hangs, the payment redirect times out, or a cached error page answers 200 in place of the real cart. That is the request you lose money on.

Perstat’s HTTP checks assert content, not just status. Point a check at your checkout page, or at a health endpoint your app exposes, and assert the string that only appears when the page really rendered: the order-summary heading, the payment-form field name, a price in the right format. A soft failure that still returns 200, a maintenance splash, a CDN error page, fails the assertion and opens an incident. Status-code, keyword, and regex assertions are all available, and a check follows up to five redirect hops, so the http-to-https-to-geo chain in front of most checkouts is followed to the real answer. Perstat does not walk a test order through payment; multi-step checks are the announced next step. The check-type reference lists all twelve types.

The certificate and the domain are single points of failure

Two of the fastest ways to take an entire store offline have nothing to do with your code. An expired TLS certificate on the checkout host is a hard outage: every current browser blocks the page with a full-screen warning, and the shopper is gone. A lapsed domain registration is worse, the whole store resolves to nothing.

Perstat watches both as first-class signals. The TLS certificate check reports days to expiry, checks the issuer against what you expect, and flags a self-signed certificate, inline on the same monitor as the HTTP check, so a renewal that quietly failed does not wait for a customer to find it. The domain check watches the registration expiry (WHOIS), the nameservers, and DNSSEC. If your receipts and order confirmations leave from your own mail domain, the SMTP and DNS-hygiene checks (SPF, DMARC, CAA) show you when that path breaks, before a buyer notices the confirmation never arrived.

A traffic spike is not an outage

The hard part of retail monitoring is that your best moment and your worst moment look alike from the outside. When a sale opens, latency climbs, a transit link somewhere saturates, one probe path slows down, and a naive monitor reads all of it as down. Now the team that should be watching real customer impact is chasing an alert that a single region invented.

Perstat does not alert on a single failed check. A monitor runs from a probe fleet on six continents, and an incident opens only when more than one region confirms the failure, with 75% of the probe nodes inside a region agreeing before that region votes at all. One slow continent during your spike does not reach the on-call phone. Nothing below that bar is discarded either: a forming incident is visible with the first failing region named, and sub-quorum divergences land on a watchlist you review on your own schedule. Check intervals are configurable down to ten seconds, with the floor set by plan: Free 300s, Pulse 60s, Sentinel 30s, Command 15s, Enterprise 10s.

Tell buyers before they open a ticket

When checkout is degraded, the support queue fills in minutes, and every unanswered buyer is a refund request or a lost order. A status page on your own domain gets ahead of that. Publish it at status.yourstore.com (custom domains are available from Sentinel up), let buyers subscribe with a confirmed double opt-in, and each one gets a single honest mail when you open an incident and another when it recovers, instead of guessing whether the problem is them or you.

Planned work gets the same honesty in the other direction. A maintenance window for a deploy or a pre-sale change is announced on the page, suppresses alerts for its duration, and stays SLA-neutral, so a release you scheduled does not dent the availability number you report later.

Evidence a marketplace partner can recompute

Sell through a marketplace or answer to a payment provider, and sooner or later someone asks for your uptime. Perstat keeps one availability record with real boundaries: each outage window runs from the last good check before it to the first good check after, never a rounded minute, and a false positive can be discarded with a logged, reversible reason, the uptime effect previewed first. Retention runs from 7 days to 2 years by plan. Hand a partner the sample SLA report and let them recompute it line by line. A one-click report export is the announced next step; today that record lives in the product and on your status page.

One honest boundary: Perstat is not APM and not real-user monitoring. It will not tell you your cart-abandonment rate, your conversion, or which query slowed a page down. It watches whether each surface a shopper touches is answering, from outside, on your interval, and proves what it saw. For funnel and performance analytics, keep the tool built for that. For whether the store is up, and the record to back it, this is the whole job.

Start with the checkout URL

Point one monitor at your checkout page and assert the content that proves it rendered. Add the TLS certificate on the same host. That is fifteen minutes, and it already covers the two failures that cost the most on a sale day.

Start monitoring free , no card. Or see pricing : Pulse 29, Sentinel 89, Command 249, Enterprise from 690 EUR per month, net and excl. VAT. Or take the product tour , no signup.