How we know if a service is really down.
Two independent sources, or the vendor's own report of an outage, before we page you. One vendor statement before we show you.
A customer alert goes out when two independent origins (for example the vendor's status page plus our own check of a product endpoint) agree on the same service, issue and scope. A verified vendor statement of impact on its own opens a visible "possible issue" labelled single-origin. It alerts the users who watch that service or have an alert rule on it only when the vendor reports a partial or major outage, and that alert is labelled "vendor-reported". Crowd chatter, social posts and forum bursts are context only: they cannot open or confirm an incident. The eleven collectors below feed that gate; most of them can only corroborate. Synthetic checks run from one runtime today, not multiple regions.
Last updated
THE 11 SIGNALS
Eleven collectors. Only some of them can vote.
Each collector below runs on its own schedule with its own failure mode. Only a few produce an origin that can open or confirm an incident: verified vendor statements, our own HTTP checks of product endpoints, an external observer, multi-resolver DNS consensus and a quorum of three verified user reports. The rest (social, forums, app reviews, BGP context, registries) are shown as context on the service page and never decide anything. Every service detail page shows exactly what each collector saw.
1 · User reports
Crowdsourced submissions from /submit, our browser extension, and partner integrations. Geolocated, session-fingerprinted, and abuse-scored.
2 · Synthetic probes
HTTP/API checks of product endpoints every few minutes from a single runtime (one region today), plus a small set of external observers. A sustained failure here is one of the origins that can confirm an incident.
3 · Vendor status (native)
We parse vendor status pages directly via their public APIs (Statuspage, Atlassian, Instatus) when available.
4 · Vendor status (LLM)
For status pages without an API, an LLM extracts current state from the rendered page. The vendor's own admission is the comparison baseline for lead-time.
5 · Multi-resolver DNS
We resolve every service's apex domain through 4 independent DNS resolvers (Google, Cloudflare, Quad9, OpenDNS). Disagreement is an early outage signal.
6 · Certificate transparency
CT log monitoring detects unexpected certificate changes — a leading indicator of misconfigured deploys and origin failures.
7 · Social firehose
Public discussion bursts on Reddit and Hacker News tied to a service. Filtered for relevance and dedicated to corroboration only.
8 · BGP route visibility
We track AS-level routing visibility via RIPEstat. When a service's network announcements drop, the rest of the internet stops seeing them.
9 · Package registry
Outages on package registries (npm, PyPI, Maven Central) ripple into every CI pipeline. We probe their public read paths directly.
10 · App Store reviews
Bursts of 1-star reviews mentioning outages on iOS App Store and Google Play within the last hour are a corroborating user signal.
Bonus signal · Corroboration only
11 · Vendor AI assistant probe
As a corroboration step (not a continuous monitor), we query the vendor's own public help/support surfaces — knowledge bases, support social accounts, in-product banners — to see whether the vendor itself is acknowledging the issue, separately from their official status page. We capture the verbatim quote and surface it on the incident page. It's the most quotable artifact we produce: the vendor's own words, with the gap to their official status page recorded when one can be measured.
01 · DETECTION
Rolling baselines, not arbitrary thresholds
Every monitored service has its own learned baseline — typical reports per hour, computed from the last 24 hours of normal activity. We open an incident only when current report volume exceeds that baseline by a configured ratio (3× by default), AND there are at least 3 reports in the active window.
That means a service with 200 reports/hour at baseline needs 600+ to trigger an incident, while a low-traffic service can trigger on 9. No fixed numbers, no surprises.
incident.open ← reports_now ≥ baseline × open_threshold (default 3.0) incident.close ← reports_now ≤ baseline × close_threshold for 2 buckets (default 1.2)
02 · CONFIDENCE
Every incident ships with a confidence score
Detection isn't binary. Each incident carries a confidenceScore between 0 and 1 derived from peak-to-baseline ratio, geographic spread of reports, agreement with synthetic probe failures, and whether the vendor has confirmed on their official page.
Low-confidence detections are visibly labeled "Possible issue" — never promoted to "Major" until multiple signals agree. We'd rather under-claim than ship a fake outage.
03 · ABUSE DEFENSE
Anti-astroturf, anti-spam, anti-pile-on
Crowdsourced systems are obvious targets for manipulation — competitors filing fake reports, bots inflating panic, users piling on for fun. We run every report through an automated suspicion scorer that looks at:
- Submission velocity per session and per IP hash (we never store raw IPs)
- Geographic clustering vs the service's known user distribution
- Issue-type entropy (real outages produce diverse complaints; bots produce identical ones)
- Cross-correlation with synthetic probe results in the same window
Reports that fail are automatically excluded from baselines and incident math, and surface in our internal moderation queue for review. Our suspicion scorer is open for audit by paid customers.
04 · CORRELATION
When 3+ services break together, we say so
A Stripe outage is interesting. A Stripe + Twilio + Auth0 outage in the same 30-minute window is almost always a shared dependency — usually a cloud region or CDN. We detect correlated bursts and surface the most-likely shared infrastructure (e.g. AWS us-east-1) right on the homepage banner.
We do not do this with magic. Each service has tagged infrastructure dependencies; when ≥3 services in a cluster share a tag, we name it. The cluster math is documented and stable.
05 · WHAT WE DO NOT DO
No mock data. Ever.
We've seen the criticism aimed at other outage trackers — that their charts contain frontend-mocked data even when no real reports exist. We hold ourselves to the opposite standard:
Every chart on PulseWatch is rendered from real records in our database.
If we have no data for a service, we say so explicitly. We do not invent activity.
Our public API returns the same numbers our UI shows. Always.
We never sell or share your individual reports. Aggregates only.
We never let a vendor pay to suppress incidents on their service page.
Verifiable outage data, by design.
Spot-check any of our claims with the REST API, included on Pro and Business plans.