Damn, is it down?

All services / ShippyPro / Nov 6, 2026 / Evidence

Evidence

Evidence: ShippyPro, Nov 6, 2026

The raw data behind this incident page: every check we ran, the regions that failed, the error codes and the user report curve. Check our work.

Our verdict: Vendor-reported issue: only the company's status page flagged it; our checks and user reports did not confirm an outage. How we verify outages

Download JSON Download CSV Also at /api/v1/outages/1011/evidence. Free to reuse with attribution.

0 of 40Checks failed in the window
0 of 4Regions failing
—Most common error code
0Peak user reports in 15 min

Window: to . Checks from 15 minutes before the start to 15 minutes after recovery (or now). Report curve: one hour either side. Tables are in UTC.

Error codes

No failed checks with an error code in this window.

http_5xx = the site answered with that server error; timeout = no answer in time; network = the connection failed; origin_reset = the connection to the site's server was reset (HTTP 520–527) and a second fetch path got no answer either; no_status = no usable answer. Bot walls (bot_*), certificate problems on a server that answers (cert_*) and maintenance pages count as up.

Regions

  • We check from: US East, US West, Europe, Asia-Pacific.
  • Failing during this incident: none recorded.

Regional probes run from Cloudflare data centers in each region. We keep the latest regional result per region, plus a timestamped timeline entry when a region starts failing during an incident, so older incidents show the failing regions and when each was first seen, not every regional probe.

Report curve

No user reports for ShippyPro in this window.

User reports per 15-minute bucket. Counts only: no reporter identity, IP address, location or text is published. We call reports a spike at 5 or more in 15 minutes.

Raw checks

40 checks, 0 failed.

All 40 checks, passes included
All checks in the window
Check time (UTC)Probe ran (UTC)ResultHTTPLatencyError codeTrigger
Pass200314 ms—scheduled
Pass200656 ms—scheduled
Pass200944 ms—scheduled
Pass200705 ms—scheduled
Pass2001070 ms—scheduled
Pass2001483 ms—scheduled
Pass2001311 ms—scheduled
Pass200693 ms—scheduled
Pass2001398 ms—on demand
Pass2001269 ms—scheduled
Pass200861 ms—scheduled
Pass200715 ms—scheduled
Pass200329 ms—on demand
Pass2002533 ms—scheduled
Pass2001413 ms—scheduled
Pass200355 ms—scheduled
Pass200354 ms—scheduled
Pass200350 ms—on demand
Pass200878 ms—scheduled
Pass200932 ms—scheduled
Pass200871 ms—scheduled
Pass2001258 ms—scheduled
Pass200995 ms—scheduled
Pass200787 ms—scheduled
Pass200865 ms—scheduled
Pass200785 ms—scheduled
Pass200983 ms—scheduled
Pass2001400 ms—scheduled
Pass200768 ms—scheduled
Pass200963 ms—scheduled
Pass2001423 ms—scheduled
Pass2001312 ms—scheduled
Pass200839 ms—scheduled
Pass200843 ms—scheduled
Pass2001297 ms—scheduled
Pass200910 ms—scheduled
Pass200730 ms—scheduled
Pass200984 ms—scheduled
Pass200740 ms—scheduled
Pass200835 ms—scheduled

Every main HTTP check of this service in the window, oldest first: the scheduled check time, when the probe actually ran, the result, HTTP status, latency and the stored error code. A failed check is a 5xx or 408 answer, a timeout or a failed connection; bot walls and maintenance pages count as passing and are noted in passing_notes.

How to check this

  • Compare checks.rows with the outage page: the first and last failed checks bound the incident times we published.
  • error_codes counts every failed check by its stored code; recount it from checks.rows.
  • report_curve.points sum to summary.reports_in_curve; the peak is summary.peak_reports_15m.
  • Disagree? Dispute it at https://damnisitdown.com/support?dispute=1011

No personal data: no reporter identities, IP addresses, emails, report text or reporter locations. User reports are aggregate 15-minute counts.

← Back to the incident · Methodology · Dispute this report