Pattern 1: a security update breaks working systems
Vendors ship fixes on a schedule, and occasionally one has a regression. Recent years have seen Windows updates that failed to install with 0x80070643 because a recovery partition was too small, updates that triggered Inaccessible Boot Device on certain storage configurations, and printing or VPN breakage after a monthly rollup.
What to do
- Do not panic-uninstall on day one — check whether the vendor has acknowledged a known issue.
- If you are affected, the fix is usually documented within days; our update-error guides track the common ones.
- For fleets: stagger deployment rings so a bad patch never hits every machine at once.
Pattern 2: a cloud provider or CDN has an outage
When a major cloud region or a content-delivery network has an incident, thousands of unrelated websites and apps return 502, 503, or 504 at once. Your device is fine.
How to tell it is not you
- The same error hits multiple unrelated sites and apps simultaneously.
- A different network (mobile data) shows the same failures.
- The provider’s status page or a third-party outage tracker confirms an incident.
- There is nothing to fix locally — wait it out, and retry with backoff rather than hammering refresh.
Pattern 3: an expired or mis-issued certificate
TLS certificates have expiry dates, and every so often a large service lets one lapse or deploys an incomplete chain. Users suddenly see ‘Your connection is not private’ across a whole platform.
What to do
- First rule out your own device: check the clock is correct and try another network.
- If it is the service’s certificate, there is no safe local workaround — do not click through security warnings on a real site.
- If you operate services: automate renewal and monitor expiry so you are never the headline.
Pattern 4: a DNS change takes something offline
A misconfigured DNS record or a resolver incident can make a service unreachable even though its servers are healthy — users get NXDOMAIN or name-not-resolved errors.
How to respond
- Try a public resolver (1.1.1.1, 8.8.8.8) — if that fixes it, your ISP’s DNS is the problem, not the site.
- Flush your DNS cache after the incident is resolved so you are not stuck on a stale record.
- For your own domains: keep TTLs sane and change records carefully.
The evergreen takeaway
Whatever the current events on technology are this month, a widespread failure is almost always one of these four: a bad patch, an infrastructure outage, a certificate lapse, or a DNS incident. In three of the four there is nothing to fix on your end — recognising that saves hours of pointless local troubleshooting. When the problem is local, it will have its own error code, and that is what this site is for.