Checked 2 minutes ago
API Shield JWT Validation Errors — started 26 days ago.
A problem is happening now — it started 26 days ago.
This longer record is here so the 48-hour picture above can mean something — without it we could tell you a problem happened, but not whether that is normal for Cloudflare.
Something was impaired on 88.47% of our checks over that window. That is how often Cloudflare was reporting a problem somewhere, which is not the same as how often it was unreachable. The longest outage we have on record ran 133h 14m.
The last 30 days of Cloudflare, one row each.
| Day | Clear | Up | Checks | Started | Longest ended |
|---|---|---|---|---|---|
| 2026-10-31 so far today | 0% | 0% | 136 | none | — |
| 2026-10-30 | 0% | 0% | 287 | none | — |
| 2026-10-29 | 0% | 0% | 287 | none | — |
| 2026-10-28 | 0% | 0% | 287 | none | — |
| 2026-10-27 | 0% | 0% | 287 | none | — |
| 2026-10-26 | 0% | 0% | 287 | none | — |
| 2026-10-25 | 0% | 0% | 287 | none | — |
| 2026-10-24 | 0% | 0% | 287 | none | — |
| 2026-10-23 | 0% | 0% | 287 | none | — |
| 2026-10-22 | 0% | 0% | 286 | none | — |
| 2026-10-21 | 0% | 0% | 287 | none | — |
| 2026-10-20 | 0% | 0% | 287 | none | — |
| 2026-10-19 | 0% | 0% | 287 | none | — |
| 2026-10-18 | 0% | 0% | 287 | none | — |
| 2026-10-17 | 0% | 0% | 288 | none | — |
| 2026-10-16 | 0% | 0% | 287 | none | — |
| 2026-10-15 | 0% | 0% | 287 | none | — |
| 2026-10-14 | 0% | 0% | 287 | none | — |
| 2026-10-13 | 0% | 0% | 281 | none | — |
| 2026-10-12 | 0% | 0% | 287 | none | — |
| 2026-10-11 | 0% | 0% | 287 | none | — |
| 2026-10-10 | 0% | 0% | 287 | none | — |
| 2026-10-09 | 0% | 0% | 287 | none | — |
| 2026-10-08 | 0% | 0% | 287 | none | — |
| 2026-10-07 | 0% | 0% | 287 | none | — |
| 2026-10-06 | 0% | 0% | 287 | none | — |
| 2026-10-05 | 45.64% | 68.99% | 287 | 1 | — |
| 2026-10-04 | 100% | 100% | 287 | none | — |
| 2026-10-03 | 37.63% | 100% | 287 | 1 | 15h 1m |
| 2026-10-02 | 99.3% | 99.3% | 287 | 1 | 14 min |
Clear is the share of checks that found nothing wrong at all; Up is the share that found Cloudflare actually reachable — a vendor reporting one impaired component scores zero on the first and a hundred on the second, and both are true. Started counts outages that began that day and Longest ended the longest that finished on it, so a problem running across midnight is counted once, on the day it began, and measured on the day it stopped.
Rows recorded before 8 August 2026 do not carry a check count — the figure was kept and the denominator was not — so their percentages are shown without one rather than with a number borrowed from somewhere else. Rows before 9 August 2026 have no Up figure either: until then we recorded only whether something was wrong, not whether it was down, and the two are different questions.
| Started | Lasted | Severity | What happened |
|---|---|---|---|
| 2026-10-05 10:55 UTC | ongoing | down | API Shield JWT Validation Errors |
| 2026-10-03 05:54 UTC | 15h 1m | having problems | Issues with Workers Build failing to start |
| 2026-10-02 21:46 UTC | 14 min | down | Cloudflare CDN experiencing increase in errors. |
| 2026-10-01 20:59 UTC | 20 min | having problems | Increased Errors for Durable Objects and R2 |
| 2026-09-30 10:31 UTC | 19h 14m | having problems | Network Performance Issues in Madrid |
| 2026-09-29 20:11 UTC | 45 min | having problems | OTP Deliverability Errors |
| 2026-09-28 20:11 UTC | 20 min | having problems | Replicate Flux Hotswap Models Stuck |
| 2026-09-26 10:20 UTC | 40 min | having problems | Cloudflare Cloud Access Security Broker (CASB) Issues |
| 2026-09-25 00:03 UTC | 20h 48m | having problems | Workflows stuck in Queued state |
| 2026-09-24 15:20 UTC | 7h 20m | having problems | Cloudflare Access updates delayed |
| 2026-09-23 08:09 UTC | 22h 37m | having problems | Increased Errors for Durable Objects |
| 2026-09-22 19:23 UTC | 12h 3m | having problems | Cloudflare One Clients are incorrectly challenged on some sites |
| 2026-09-22 14:37 UTC | 2h 3m | having problems | Elevated error rates for Stream Live LL-HLS |
| 2026-09-22 09:36 UTC | 3h 20m | having problems | Partial loss of analytics for Fedramp High customers |
| 2026-09-22 02:25 UTC | 1h 15m | having problems | Network connectivity issues in LHR, London |
| 2026-09-21 12:42 UTC | 44 min | partly down | Unable to start containers in Asia-Pacific |
| 2026-09-21 09:37 UTC | 13 min | having problems | Unable to register certain domains |
| 2026-09-18 06:42 UTC | 1h 38m | having problems | Cloudflare Dashboard Workers KV Issue |
| 2026-09-17 23:37 UTC | 1h 18m | having problems | Increased Errors for Durable Objects and Downstream Services in Asia Pacific (APAC) Region |
| 2026-09-17 18:29 UTC | 1h 31m | having problems | Network Performance Issues in Ashburn, VA, United States |
Cloudflare publishes over 460 components — one for nearly every datacenter — which makes their status page unusually detailed and unusually easy to misread.
On any ordinary day roughly 40 of Cloudflare's 460+ components are re-routed or in maintenance while the service is completely fine. Taking the worst component would report a partial outage almost permanently. We keep Cloudflare's own banner unless an incident is open or a quarter of components are unhappy — this specific service is why that rule exists.
Status pages report the vendor's view of their own service, and they lag real
outages — often by many minutes, sometimes by hours, because a human usually has to
confirm before anything is posted. They also can't see the two things most likely to
be wrong at your end.
The first is your own connection under load. A line that idles at 20 ms can
jump to 300 ms the moment something starts uploading, which drops you from sessions
and looks exactly like a server fault. Your plan speed says nothing about this; it's
called bufferbloat and almost nobody measures it.
The second is where everyone else in your group is. A service can be healthy in your
region and unwell in theirs, and if one person is hosting, their problem is everyone's
problem.
Cloudflare being fine where you are does not mean it is fine for everyone in your group. The live dashboard resolves status against each person's own region, and will tell you which of your friends is in an affected area — plus who has the connection to host, which is usually a different question from who has the fastest plan.
Worth a look when more than one thing feels broken at once: if several are genuinely down together, the fault is usually something they share rather than anything at your end. We are not claiming these particular services fail together — the live dashboard says when they actually do.