Cloud Status Heatmap
One-glance operational status across AWS, Azure, Google Cloud, Cloudflare, and GitHub — pulled from each provider's public status feed.
When a business-critical change goes sideways, the first question CAB members ask is almost always the same: is it us, or is a cloud provider having a bad day? This heatmap collapses the answer into a single row of tiles: AWS, Microsoft Azure, Google Cloud, Cloudflare, and GitHub — the five providers whose incidents cause the most change-related misattributions. Each tile is colored from the provider's own public status feed (green for operational, amber for degraded, red for a declared outage), links straight to the provider's status page for detail, and surfaces the current top-line summary line. The data is polled hourly and cached in this page's bundled JSON so the tool loads instantly and remains useful even when the underlying feeds are throttling. Bookmark this page as the very first tab you open during an incident bridge — before Slack, before the runbook, before the CAB chat. If the tile is red, escalate to provider support in parallel with your own diagnostics.
All AWS services operating normally.
No active regional incidents reported.
All Google Cloud services operational.
Minor Service Outage
All Systems Operational
Snapshot generated 2026-07-24T08:02:34Z. Refresh cadence: hourly. Sources: Amazon Web Services , Microsoft Azure , Google Cloud , Cloudflare , GitHub .
About this tool
A deployment can touch more providers than its change record suggests: a cloud region, DNS or edge service, source control platform, identity path, and external monitoring endpoint may all influence the result. The heatmap places published status information from AWS, Azure, Google Cloud, Cloudflare, and GitHub in one operational view. The grouping supports a disciplined initial check. It is useful at the start of a maintenance window and when an incident commander needs to see whether providers acknowledge a related condition.
Read the display as a provider communication layer, not an impact detector. Open the underlying notice for its scope, update history, affected regions, and mitigation language. Then compare that notice with telemetry from the service, customer reports, dependency maps, and recent changes. A green or unremarkable provider page cannot prove the absence of an issue, particularly where an impact is regional, tenant-specific, network-path dependent, or not yet recognized by the provider.
How to read the output
- Open affected notices to check scope, timestamps, and provider updates.
- Compare provider statements with internal telemetry and current dependency mapping.
- Record provider references separately from the incident's confirmed internal event timeline.
- Avoid using a green status indicator as proof of normal service.
What this does not tell you
- Provider status pages reflect provider communications and may lag customer-observed impact, diagnosis, or issue acknowledgment.
- A consolidated view can omit tenant-specific, regional, network-path, or third-party dependency conditions affecting one service.
- Status notices do not establish causation between a provider event and an organization's failed change or degraded service.
Data sources
Free to use, no account required, and nothing you enter is transmitted to this site — the tool runs entirely in your browser.