How to Detect Silent Failures: Website Up but Orders Stopped

Your uptime monitor says everything is fine. The homepage loads, the checkout returns 200 OK, and the dashboard is green. But no orders have come in since lunch. This is a silent failure, and learning how to detect silent failures is the difference between losing an hour of sales and losing a whole weekend. This guide explains what silent failures are, why normal uptime checks can't see them, and how to set up an alert that fires when orders, signups, or payments quietly stop, even while the site is technically up.

Short answer: a silent failure is when your site or app keeps responding normally but stops doing its job, with no error, crash, or downtime alert. To detect silent failures, you watch the outcome itself (orders per hour, new signups, failed payments) as a number in a JSON API, and alert when that number drops, crosses a threshold, or goes the wrong way.

What is a silent failure?

A silent failure is a problem that produces no error signal. Your server doesn't go down, it doesn't throw a 500, and nothing obvious shows up in the logs. The system keeps answering requests, but something important has stopped working.

For a store or SaaS app, that usually means one of these:

• The payment gateway was left in test mode after a change, so checkout looks normal but no real payments go through.
• A plugin or theme update broke the "Place order" button with a JavaScript error. The page still returns 200.
• A webhook stopped firing. Payments succeed at the processor, but orders never get created or confirmed in your store.
• An API returns 200 with an error or empty data, like {"orders": []} or {"error": "service unavailable"}.
• A background job or queue stalls, so emails, invoices, or syncs pile up without anyone noticing.

Silent failure vs downtime

	Downtime	Silent failure
What happens	The site or API stops responding	The site responds but does nothing useful
Error signal	Timeouts, 5xx codes	None, everything returns 200
Caught by uptime monitoring	Yes, within one check interval	No
How people usually find out	An alert	A customer email, or the end-of-day sales report
Cost over time	Stops growing once it's fixed	Keeps growing for every hour nobody notices

Downtime is loud; a silent failure is quiet, which is why it costs more. Our post on how e-commerce stores lose money to downtime covers the cost side. This guide covers the failures that never show up as downtime.

Why uptime monitoring misses silent failures

An uptime check asks one question: did this URL answer, with the right status code, fast enough? That's an essential question. But "the server responded" and "the business is working" are different claims.

Even a better API check that validates the status code (see why an HTTP 200 isn't always healthy) only tells you the endpoint is answering correctly right now. It doesn't tell you that nobody has successfully bought anything for three hours. If you're not sure what each code means, our guide to HTTP status codes explained is a good refresher.

To catch a silent failure, you need to watch the result of the work, not the thing doing the work. That's what business metrics monitoring means in practice: you turn "orders are flowing" into a number and alert when the number looks wrong.

How to detect silent failures: the 4 main approaches

Most teams use one or more of these. Here's how they compare:

Approach	What it catches	Effort	Weak spot
Uptime and status-code checks	Crashes, 5xx errors, timeouts	Low	Can't see anything that still returns 200
Endpoint tests with assertions	Wrong content, missing JSON fields, slow responses	Low to medium	Checks one response, not the trend over time
JSON value monitoring (Data Monitors)	Orders, signups, revenue, or queue depth dropping or stalling	Medium (you expose one number)	Needs a sensible threshold for quiet hours
Scripts and workflow tools (Shopify Flow, n8n, cron jobs)	Whatever you code	Medium to high	You maintain it, and it can fail silently too

Some dedicated tools add anomaly detection, comparing each hour to the same hour in past weeks. For most small businesses and agencies, a simple rule like "alert me if orders in the last hour go below 1" gets most of the benefit.

Step by step: alert when orders stop with a JSON API value

The same setup works for signups, payments, leads, or any number your business depends on.

1. Pick the number that proves the business is working

Ask: "If this number went to zero, would I want to know within the hour?" Good candidates:

• Orders in the last 60 minutes
• Successful payments today
• New signups or trial starts in the last hour
• Contact-form leads today
• Minutes since the last order
• Jobs waiting in a queue (where high is bad)

2. Expose it as a small JSON endpoint

The easiest thing to monitor is a tiny read-only endpoint that returns just the numbers you care about, for example:

{
  "orders_last_hour": 14,
  "minutes_since_last_order": 3,
  "failed_payments_last_hour": 0,
  "queue_depth": 2
}

Keep it to aggregate counts only, with no customer names, emails, or order details. On WooCommerce that can be a small custom REST route; on a custom app it's a few lines in your existing API.

3. Turn "stopped" into a threshold

This is the most important step. A running total that never resets is hard to alert on, because "the value didn't change" isn't an error. Instead, shape the value so a stall becomes a clear threshold:

• orders_last_hour goes below 1, which means no orders in the past hour
• minutes_since_last_order goes above 90, which means the order stream has stalled
• failed_payments_last_hour goes above 5, which means checkout is breaking
• queue_depth goes above 500, which means a worker has stopped

A windowed count or a "time since last event" value is what makes an "alert when orders stop" rule reliable.

4. Create a Data Monitor in ismysiteup

ismysiteup's Data Monitors watch a value inside an API's JSON response and alert you when it stalls or moves the wrong way, even if the page still returns 200. You point a Data Monitor at your endpoint, choose the fields to watch, and pick a condition for each one. These are the available conditions:

Condition	Plain English	Good for
Increased	Tell me when this goes up	Error counts, refunds, queue depth
Decreased	Tell me when this goes down	Orders, signups, stock
Changed	Tell me when this changes	Config values, versions, prices
Goes above N	Tell me when it reaches a number	Failed payments, minutes since last order
Goes below N	Drops below a number	Orders per hour, active users, balance
Increased by ≥ N or ≥ N%	A jump of at least N	Sudden spikes in errors or cancellations
Decreased by ≥ N or ≥ N%	A drop of at least N	Revenue or conversion falling off a cliff
Equals / Does not equal	Becomes, or stops being, an exact value	"status": "ok" turning into something else
Contains	Contains some text	Error messages appearing in a field
New item in list	A new item appears	New orders, new tickets, new entries

For the order example, the cleanest rules are orders_last_hour goes below 1, plus minutes_since_last_order goes above whatever counts as unusual for your store.

5. Choose a check frequency that matches your sales volume

How often the value is checked depends on your plan:

Plan	Data Monitors	Watched fields per monitor	Data check frequency
Free ($0)	1	3	Every hour
Pro ($9/mo)	10	10	Every 5 minutes
Business ($24/mo)	50	10	Every minute

Pro and Business are listed as coming soon, so see the pricing page for current details and availability. An hourly check suits an "orders in the last hour" rule. Faster checks matter for high-volume stores, where every few minutes without sales costs real money.

6. Send the alert somewhere you'll actually see it

A silent failure alert is useless if it lands in an inbox you check once a day. ismysiteup offers WhatsApp, Telegram, Slack, and email alerts on every plan, including Free. For revenue alerts, a phone notification works best. See how to set up WhatsApp website alerts, Telegram alerts, or the Slack alerts setup guide for a shared team channel.

Avoiding false alarms on quiet hours

The most common complaint about no-orders alerts is noise. A small shop might go three hours overnight without a sale, and an alert that cries wolf gets muted. A few ways to keep alerts meaningful:

• Match the window to your volume. If you average 2 orders an hour, "zero in 60 minutes" can happen by chance. Use "zero in 3 hours" or a minutes_since_last_order threshold of 180 instead.
• Let the endpoint handle business hours. Your JSON endpoint can return a neutral value (or skip the field) outside trading hours, so the rule only bites when it should.
• Watch more than one signal. A drop in orders and a rise in failed payments is a much stronger signal than either one alone.
• Keep regular uptime checks running. If the site is actually down, your uptime monitor fires first.

Other silent failures worth monitoring

The same "watch the number" approach covers other quiet problems too:

• Signups dropped to zero after a form or captcha change
• Inventory that hits zero on a best-seller
• An API that returns 200 but no data, such as an empty results array
• A sync or import job whose "last updated" value stops moving

If you run sites for clients, this is a strong add-on to normal uptime checks. Our guide to monitoring client websites covers how to organize monitors by client.

Get started

You can try this today with the Free plan: 5 uptime monitors plus 1 Data Monitor with 3 watched fields, no credit card. Create a free ismysiteup account, add a regular uptime monitor for your store, then add a Data Monitor for your orders endpoint. If you just want to see whether a site is responding right now, use the free instant website checker first.

FAQ

What is a silent failure?

A silent failure is when a website, app, or background process stops doing its job without producing any error. The site returns 200 OK, so monitoring stays green while orders or signups quietly stop.

How do you detect silent failures?

Monitor the outcome instead of the server. Expose a key business number, such as orders in the last hour, as a JSON value, and alert when it drops below a threshold, decreases sharply, or stops moving. Pair that with regular uptime checks.

Why does my API return 200 but no data?

A 200 only means the server answered without crashing. The API can still return an empty array, an error message in the body, or stale cached data. Monitoring a specific JSON field, not just the status code, catches this.

How do I set up an alert if no orders come in for a certain time?

Create an endpoint that returns orders_last_hour or minutes_since_last_order, then set a Data Monitor rule such as "goes below 1" or "goes above 90". Choose a time window that fits your normal order volume to avoid false alarms.

Why is my website getting traffic but no sales?

It can be a broken checkout, a payment gateway in test mode, a failed plugin update, or a shipping error, as well as pricing or marketing issues. If sales drop suddenly to zero, check for a technical silent failure first.

Can uptime monitoring detect a broken checkout?

Only if the checkout returns an error status or times out. Most checkout bugs still return 200, so you need a check on the result, such as an order-count alert, alongside uptime monitoring.