Avoiding False 'Site Down' Signals in Ecommerce Monitoring

You get an alert at 11 PM: "Competitor site is down." You check manually and the site loads fine. The next morning, another alert—same site, same "down" status. You check again, and it is working perfectly. After a week of these phantom alerts, you mute the notification entirely. Two months later, the site actually goes down for 18 hours and you miss it because you trained yourself to ignore the signal.

This is the false positive trap, and it is one of the most common failure modes in ecommerce monitoring. The solution is not better alerting—it is understanding why ecommerce sites produce false signals in the first place and building monitoring that accounts for those realities.

Why Ecommerce Sites Are Hard to Monitor

Traditional uptime monitoring was built for a simpler web. Ping a server, check for a 200 response, done. Ecommerce sites in 2026 are far more complex. Most sit behind multiple layers of infrastructure that actively interfere with automated monitoring.

The typical stack for a mid-size ecommerce store includes a CDN (Cloudflare, Fastly, or Akamai), a web application firewall, automated-traffic detection middleware, geographic load balancing, and possibly a headless frontend served from a different origin than the API. Each of these layers can return responses that look like failures to a monitoring tool but are actually the site functioning exactly as intended.

A Cloudflare challenge page returns a 403 status code. To a naive monitoring tool, that is an error. To a human visitor, it is a five-second interstitial before the site loads normally. Rate limiting returns a 429—again, an "error" that has nothing to do with actual availability. Geo-blocking might return a 403 or a redirect to a regional storefront, neither of which indicates downtime.

The fundamental problem is that ecommerce infrastructure is designed to protect against automated access, and monitoring tools are, by definition, automated access. Monitoring requests naturally encounter the same protections designed for all automated traffic.

Common False Positive Sources

Understanding the specific mechanisms that generate false signals helps you build monitoring that accounts for them. Here are the most frequent culprits.

Cloudflare and CDN challenge pages. When Cloudflare's traffic management detects automated requests, it serves a JavaScript challenge or CAPTCHA instead of the actual page. The HTTP response is typically a 403 or a 503 with a specific Cloudflare page body. The site is fully operational—Cloudflare is simply filtering the monitoring request.

Automated-traffic detection and request analysis. Services like PerimeterX, DataDome, and Kasada analyze request patterns and browser signatures. Monitoring requests that lack realistic browser characteristics get blocked. The block response varies—sometimes it is a 403, sometimes a 200 with a challenge page in the body, and sometimes a redirect to a verification endpoint.

Rate limiting. If your monitoring checks a site too frequently, the site's rate limiter kicks in and returns 429 responses. This is especially common when monitoring multiple pages or products on the same store. The site is up; you are just hitting it too hard.

CDN cache misses and origin errors. Occasionally, a CDN cache expires and the origin server is slow to respond or temporarily returns a 5xx error. The next request might succeed because the CDN retried or routed to a different origin. These transient errors are normal in distributed systems and do not indicate meaningful downtime.

TLS certificate renewals and rotations. During certificate rotation, there can be a brief window where a monitoring request hits a node with an expired or mismatched certificate. The connection fails, an alert fires, and by the time you check, the rotation is complete and everything works.

Geographic routing differences. The site might be fully operational in its primary market but slow or unavailable from the region where your monitoring runs. This is relevant because monitoring infrastructure and the store's customers are often in different locations.

How Bonesaw Handles WAF Detection

Bonesaw approaches the false positive problem at the protocol level rather than treating it as an alerting configuration issue. When a monitoring request returns a non-200 response, the system does not immediately classify it as downtime. Instead, it analyzes the response characteristics to determine what actually happened.

WAF detection is a core part of this analysis. When Bonesaw encounters a response that matches known WAF challenge patterns—Cloudflare's challenge page signatures, common automated-traffic detection interstitials, or rate limit responses—it classifies the event as a WAF interaction rather than an outage. This classification is surfaced separately in the monitoring data so you can see that the site is protected but operational, rather than seeing a misleading "down" status.

This matters because the operational response to "site is behind a WAF that is blocking our monitor" is fundamentally different from "site is down." The first might require adjusting your monitoring approach. The second might require notifying your team, updating your product availability, or adjusting ad spend.

The WAF detection also feeds into Bonesaw's crawl system. When monitoring a Shopify or Magento store, encountering a WAF response triggers adaptive behavior—backing off request frequency, adjusting timing—rather than continuing to send requests to a site that is actively filtering the traffic.

Distinguishing Real Downtime From Protection Mechanisms

The practical question for operators is: when should you actually be concerned about a competitor's availability? Here are the heuristics that separate real outages from monitoring artifacts.

Duration matters more than occurrence. A single failed check means almost nothing. Three consecutive failed checks over 15 minutes might mean something. Failed checks persisting for an hour or more, with no WAF signatures in the responses, strongly suggest a real issue. Bonesaw tracks consecutive failure counts rather than isolated events for exactly this reason.

Response characteristics tell the story. A connection timeout (no response at all) is more concerning than a 403 or 503 with a response body. A DNS resolution failure is more concerning than an HTTP error. A TLS handshake failure might indicate an expired certificate, which is a real operational issue even if the server behind it is running.

Cross-reference with public signals. If your monitoring shows a site as down and their social media goes quiet, their last tweet was 12 hours ago, and DownDetector shows reports—that is a real outage. If your monitoring shows a site as down but customers are posting about purchases they just made, your monitor is being blocked.

Check the response body, not just the status code. A 200 response with a Cloudflare challenge in the body is not "up" in any meaningful sense for a monitoring tool, but the site is operational. A 503 with a "scheduled maintenance" page is a real outage, but a planned one. The status code alone is insufficient.

Reducing Alert Fatigue

Alert fatigue is the silent killer of monitoring programs. When operators stop trusting their alerts, the monitoring system becomes decoration—it exists, it runs, but nobody acts on it. If you want a practical walkthrough of triaging issues once they appear in your dashboard, the store health issue triage guide covers the decision flow.

The most effective strategy for reducing alert fatigue is raising the bar for what constitutes an alertable event. Instead of alerting on every non-200 response, alert on confirmed outages: multiple consecutive failures over a meaningful time window, with WAF and rate-limit responses filtered out.

Bonesaw's approach separates monitoring events into categories—WAF blocks, rate limits, transient errors, and confirmed availability issues—so that alerts only fire for the last category. The other events are still recorded and visible in the monitoring dashboard, but they do not trigger notifications. This means when you do get an alert, it carries real signal.

Beyond tool configuration, organizational discipline matters. Establish a rule: every alert that fires and turns out to be a false positive should trigger a review of the alert rule that generated it. Either tighten the threshold, add an exclusion, or remove the rule. Over time, this pruning process converges on an alert set that is almost entirely actionable.

Setting Up Meaningful Uptime Baselines

The concept of "99.9% uptime" is misleading for ecommerce monitoring because it assumes clean binary availability. In practice, ecommerce sites exist on a spectrum: fully available, partially available (some pages load, others do not), available but degraded (slow responses), available but blocked (WAF), and actually down.

A more useful baseline acknowledges this spectrum. Track successful monitoring checks as a percentage, but exclude WAF-blocked checks from the availability calculation. A site that returns 200 responses 95% of the time and WAF challenges 5% of the time is effectively at 100% uptime—the 5% "failures" are protection mechanisms, not outages.

Establish per-store baselines over a two-week period before relying on the data for operational decisions. Some stores will show a consistent pattern of occasional WAF blocks that is normal for that store. Others will show clean 200 responses consistently. The baseline tells you what "normal" looks like for each specific store, so that genuine deviations stand out clearly.

Bonesaw builds these baselines automatically as it monitors stores over time, which means anomaly detection for availability is calibrated to each store's actual behavior rather than a generic threshold that generates false positives for heavily-protected sites.

Frequently Asked Questions

Why does my monitor show a site as down when I can access it in my browser?

The most likely explanation is that the site's automated-traffic detection or WAF is filtering your monitoring tool's requests while allowing normal browser traffic through. Browsers carry cookies, execute JavaScript, and present browser signatures that automated monitoring requests typically do not. The site is up—it is just distinguishing between human visitors and automated checks. Bonesaw handles this by detecting WAF responses and classifying them separately from actual downtime.

How many consecutive failures should trigger an alert?

For most ecommerce monitoring use cases, three to five consecutive failures over a 15-to-30-minute window is a reasonable threshold. This filters out transient network issues and CDN hiccups while still catching real outages quickly enough to be useful. If you are monitoring a site that is frequently WAF-blocked, you may need to raise this threshold or rely on WAF-aware monitoring that filters those responses before applying the failure count.

Can rate limiting from my monitoring actually cause problems for the site I am monitoring?

It is unlikely that monitoring alone would cause availability issues for a production ecommerce site, but aggressive monitoring can get your IP address blocked, which creates a self-inflicted false positive. More importantly, excessive automated requests are inconsiderate and may violate the site's terms of service. Bonesaw uses adaptive rate limiting and respects crawl delays to avoid triggering rate limits in the first place.

Should I monitor competitor sites from multiple geographic locations?

If your customers are in multiple regions and the competitor uses geographic routing, monitoring from a single location can miss region-specific outages. However, for most operators, single-location monitoring is sufficient as a starting point. The additional complexity of multi-region monitoring is worth it only if you have evidence that geographic availability differences are affecting your competitive landscape.

Does Bonesaw interfere with the sites it monitors?

No. Bonesaw monitors publicly accessible storefront pages and does not access private customer data or internal systems. It uses adaptive rate limiting and respects standard crawl policies to minimize its footprint on the sites it monitors.