How we know if a service is really down.
A multidimensional detection matrix — 11 independent signals, weighted in real time.
Most outage trackers ask you to trust a single signal — a crowd-sourced report graph, or a vendor's own status page. We don't. PulseWatch fuses 11 independent signal sources and publishes the math, so you can verify every claim we make. The vendor's status page is one of those signals. Not the most important one.
Last updated
THE 11 SIGNALS
Eleven independent sources. Eleven independent failure modes.
Each signal below runs on its own infrastructure with its own failure mode. When two or three light up together, the incident is real. When only one fires, it's noise. Most aggregators run a single signal — Downdetector ships crowdsource reports, StatusGator rebroadcasts vendor status pages. We run all eleven in parallel and publish exactly what each is seeing on every service detail page.
1 · User reports
Crowdsourced submissions from /submit, our browser extension, and partner integrations. Geolocated, session-fingerprinted, and abuse-scored.
2 · Synthetic probes
Independent HTTP/API monitors hit each service from multiple regions every few minutes. Confirms or contradicts the crowd signal.
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, before their PR-controlled status page catches up.
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.