For e-commerce

Checkout is down. Who finds out first?

Watch the storefront, the checkout API, the payment gateway and search at the pace sales happen. When something breaks, customers see a page that says you know, and your team hears about it before the abandoned carts pile up.

Free for one monitor. No card needed.

Monitors4 up · 1 degraded
  • shop.northwind.co
    HTTPS · every 30s
    210 ms
  • shop.northwind.co/api/checkout
    HTTPS · every 30s
    3 100 ms
  • pay.northwind.co:443
    TCP · every 30s
    38 ms
  • search.northwind.co
    HTTPS · every 1 min
    142 ms
  • Order webhooks
    Heartbeat · every 5 min
    2 min ago
30s
Fastest check
ms
Slow counts as down
24h · 1h
Maintenance reminders
$0
Per-subscriber fees

Black Friday, 11:40

The outage that isn't a 500.

11:40

Checkout is slow, not broken

Every request still returns 200. It just takes four seconds. Your response time assertion says that is a failure, and after two of them the monitor agrees.

11:41

The page says so first

The Checkout component flips to Degraded and an incident opens from your template. Subscribers on SMS and email hear about it before the first “is your site down?” tweet.

11:58

Back to normal, in writing

Checks pass, the incident moves to Monitoring, you post the resolution. The timeline is there for the post-mortem and for the customers who ask.

Assert on more than “is it up”

A store that returns 200 in six seconds is losing sales. Set a response time limit on the checkout endpoint, check for a string only a working page prints, and let the timing breakdown tell you whether it is the app or the network.

  • Status code, response time and body text assertions, per monitor
  • Every 30 seconds on Team, so a bad deploy is caught inside a minute
  • TCP checks on the payment gateway, heartbeats on the order webhook consumer
GET shop.northwind.co/api/checkout200 OK
  • Status code is 200
  • Responds within 1 000 ms
  • Body contains "cart_total"
  • Certificate valid for 61 more days
Frankfurt 182Virginia 240Oregon 268Singapore 311Sydney 344São Paulo 296

Plan the migration. Tell customers first.

Payment provider switch on Sunday at 2 am? Schedule it. The page shows Maintenance instead of Outage, subscribers get reminders the day before and the hour before, and the incident history does not get a black mark.

  • Windows with a start, an end and the components they touch
  • Reminders you can change per window
  • Finish early and the page updates the moment you mark it done
Payment provider migrationScheduled
Sun 20 Sep, 02:00to03:30 UTC

Orders placed during the window are held and processed when it ends. Browsing and carts keep working.

AffectsCheckoutPayments
Subscribers hear about it 24 h before, 1 h before, when it starts, when it ends.

Certificates that don't expire mid-sale

An expired certificate on a store is a browser warning on the checkout page. The SSL monitor reads the expiry, verifies the chain and reminds you at 30, 14, 7 and 1 days, on the channels your team reads.

  • Covers the storefront, the payment host and the API
  • Works with short-lived certificates, where the renewal job failing quietly is the usual cause
  • Reminders re-arm after every renewal
shop.northwind.coExpires in 61 days
Issued 14 AugExpires 12 Nov

Reminder sent 30 days out to #ops and 2 email addresses. Next one at 14 days.

  1. status.tidepool.ioLeaf
  2. R11Intermediate
  3. ISRG Root X1Root

Issued by Let's Encrypt. Chain verified against the system trust store, hostname matched, not revoked.

What stores set up first

The checkout check, the certificate reminder, and the port under the payment gateway.

Questions from store owners

Watch the checkout like it's your best salesperson.

One monitor and a status page, free. No card needed.

Start monitoring