Checkout Down Is Not Site Down

The homepage loads. It loads from the owner's laptop and from their phone, and the uptime monitor has been green all weekend. The cart, meanwhile, has returned an error since a plugin updated itself on Friday night. Visitors browse, add something to the basket, hit the error and leave. Nobody complains, because people who cannot give you money rarely write in to say so.

On Monday someone notices sales are down and assumes it is the weather.

A shop is not up because its homepage is up. It is up when someone can find a product and pay for it. Monitoring a store means watching that path, and being honest about the parts of it a check cannot see.

The homepage is the least useful page to monitor

It is also the page almost everyone monitors, because it is the URL everyone knows.

On most stores the homepage is the most heavily cached page on the site. A CDN or a page cache can keep serving it for minutes or hours after the application behind it has failed. It also touches the fewest of the things that take your money: no cart, no session, no stock check, no payment script.

Keep a monitor on it, because a dead homepage is still a dead store. Just don't let it be the only one.

Follow the money

Walk the path a customer takes and put a monitor on each step that uses a different part of the system:

Pick a real product that will stay in stock, and a category that will not be renamed next month. Otherwise the monitor starts failing with a 404 the day someone tidies the catalogue.

The cart is the most important monitor on the list. It is the first step that has to be generated fresh for every visitor, so it is the first place an application failure shows up behind a healthy cache. On most platforms, loading the cart with no session simply shows an empty basket, which is a perfectly good thing to check.

If you run the shop on your own code, add a health route that checks the database and cache the checkout depends on. What to put behind a /health endpoint covers how to build one that does not lie to you.

What an uptime check can and cannot prove

It is worth being precise here, because monitoring vendors are not always.

An uptime check makes a request and looks at the answer. A successful check proves the server answered that URL, with a success status, within the timeout, over a valid TLS connection. That catches a lot: crashed application servers, database outages that surface as 500 errors, expired certificates, DNS failures, a CDN that cannot reach the origin, a firewall rule that blocks everyone.

It cannot add a product to a basket, fill in a delivery address, or pay. A checkout can fail at the payment step while every page on the path loads perfectly. Testing that needs a scripted browser running a real purchase flow, which is a different kind of tool. Barkme does not do it.

Two things cover most of that gap for a small store:

• Watch the order rate. Most store platforms can alert when no orders have come in for a period that would normally have several. A sudden drop to zero during a busy hour catches failures no outside check ever will, including the ones in someone else's system.
• Know your checkout's dependencies. Payment gateways, shipping rate calculators, tax services, fraud screening, search providers. Subscribe to each one's status page and route the updates to the same place your own alerts go.

If your checkout is hosted by the payment provider on their own domain, it is their uptime, not yours. Barkme only monitors hosts under domains you have verified you own, so it will not watch it. Their status page will.

Failures that do not take anything down

Some of the costliest failures for a store involve no outage at all. The site answers, the checks pass, and money leaks anyway.

The certificate

A certificate expires at three on a Saturday morning. Every visitor gets a full-page browser warning that reads, to a shopper, like "this store has been hacked". The owner's own browser may still have a working session and see nothing wrong. The weekend's ad spend keeps sending paying traffic straight into the warning.

Barkme checks the certificate on every verified domain daily and warns at 30, 14, 7 and 1 days before expiry, so there is time to fix a broken renewal. If one gets through anyway, a TLS failure counts as a failed check, so the monitors catch it within minutes instead of on Monday. The expiry dates that take websites down covers why automatic renewal fails more often than people expect.

The domain

The registration lapses because the renewal reminder went to spam and the card on file had expired. When a domain expires, the site, the email and the payment callbacks all stop at once. The same daily check watches the registrar expiry date, with the same warnings.

The order confirmation that never arrives

This one is invisible from the inside. Order confirmations start landing in spam, or bouncing. The customer is not sure their order went through, so they order again, or call, or dispute the charge. Nobody on your side sees an error, because as far as your server is concerned the email was sent.

Two causes account for most of it. Either the domain's SPF, DKIM and DMARC records are missing or broken, so mail providers cannot confirm the mail is really yours, or the domain has landed on a blacklist. SPF, DKIM and DMARC, explained covers the first. For the second, Barkme checks every verified domain daily against the Spamhaus DBL, SURBL and URIBL blacklists, and against the DNS filters that block sites for visitors, and alerts you when the domain is listed and again when it clears. When your domain lands on a blacklist covers how to get off one.

Don't let your own shop block the monitor

Stores tend to sit behind aggressive bot protection, because stores attract bots. A challenge page usually comes back as a 403 or a 503, which is a failed check, and a monitor that trips a bot rule reports a perfectly healthy store as down.

Allowlist your monitor. Barkme's checks come from a fixed prober address, shown under Settings and Team as "Monitoring Prober", and carry a Referer header starting with Barkme-. Most bot protection and firewall tools let you exempt either one.

How often to check each page

Match the interval to what a minute of downtime costs on that page. The cart and the health route deserve the fastest interval you have. The homepage and the category page can check every minute. The account login page can check every few minutes. How often should you check your website is up? covers the reasoning.

Before a sale, a campaign or a big email send, check that every monitor is green and every alert channel still works. Then avoid deploying during the campaign itself. More stores go down from their own deploy in the middle of a sale than from the traffic.

A starter setup

For a typical small store:

1. Verify the store's domain, so SSL, registrar expiry and blacklist checks run daily.
2. Monitor the cart at the fastest interval.
3. Monitor a health route, if you have one, at the same interval.
4. Monitor the homepage and one product page every minute.
5. Allowlist the monitor in your bot protection.
6. Send alerts to your phone, not only to email, and send expiry warnings to whoever can renew.
7. Turn on a no-orders alert in your store platform.
8. Check that SPF, DKIM and DMARC pass for your order confirmations.

That fits comfortably on Barkme's Founder plan, which allows 30 monitors and 30-second checks. On the free plan, three monitors at one-minute checks cover the cart, a health route and the homepage.

None of it is complicated, and none of it is the homepage. The page that tells you whether you are making money is somewhere further in, and that is the one to watch.

How it works follows a check from the first failed request to the recovery notice, and the F.A.Q covers domain verification and the daily domain checks.