Why your status page stays green during an outage

A status page stays green during an outage when something on the path from failure to red banner is broken: the page or the tool used to update it runs on the infrastructure that failed, the checks feeding it run inside your own stack, nothing checks the part that broke, or the person who has to post it has not found out yet or cannot log in.

Three of the four have happened to large, well-staffed operators and are written down in their own incident reports or status history. The fourth follows from how a page is wired. They also fail independently. The standard advice, "host your status page somewhere else", closes one of them and leaves the rest open.

The page or its tools sit inside the blast radius

On 28 February 2017, a command entered with a wrong input took out a large part of Amazon S3 in the Northern Virginia (US-EAST-1) region, starting at 9:37AM PST. The AWS summary of the S3 disruption says:

From the beginning of this event until 11:37AM PST, we were unable to update the individual services’ status on the AWS Service Health Dashboard (SHD) because of a dependency the SHD administration console has on Amazon S3.

The dashboard itself loaded. What failed was the admin console behind it, for two hours. AWS fell back to its Twitter account and banner text on the dashboard, and afterwards changed the console "to run across multiple AWS regions".

Three years later the dependency moved somewhere less obvious. During the Kinesis event on 25 November 2020, where the first alarms fired at 5:15 AM PST, AWS "were unable to update the Service Health Dashboard because the tool we use to post these updates itself uses Cognito, which was impacted by this event." Amazon Cognito is an AWS identity and sign-in service. The dashboard was up; the posting tool depended on a service that was down.

The AWS network event on 7 December 2021 started at 7:30 AM PST. AWS had a standby region for its dashboard tooling by then, and it still did not help in time: "the networking congestion impaired our Service Health Dashboard tooling from appropriately failing over to our standby region." The report gives 8:22 AM PST as the point where updates were going out, 52 minutes after the start. A failover that needs the broken network to complete is not a failover.

Separate hosting is necessary. It is also not enough. During the Cloudflare outage on 18 November 2025 (failures began at 11:20 UTC), Cloudflare writes that "Cloudflare’s status page went down", and that "The status page is hosted completely off Cloudflare’s infrastructure with no dependencies on Cloudflare." It was a coincidence, not a shared dependency. It still cost them: "it led some of the team diagnosing the issue to believe that an attacker may be targeting both our systems as well as our status page." A status page is a production URL with its own failure modes, and it needs its own external check like any other.

Hosting the page elsewhere also does not move its hostname. Here is GitLab's status page at the time of writing:

$ dig +noall +answer status.gitlab.com
status.gitlab.com.	259	IN	CNAME	34754878.hostedstatus.com.
34754878.hostedstatus.com. 259	IN	CNAME	d2c9567qmz0pih.cloudfront.net.
d2c9567qmz0pih.cloudfront.net. 19 IN	A	3.171.214.45

$ dig +short NS gitlab.com
diva.ns.cloudflare.com.
jermaine.ns.cloudflare.com.

The page is served by a hosted status provider through CloudFront, well away from GitLab's own application. The first step of resolving status.gitlab.com still goes to the nameservers for gitlab.com, which are Cloudflare's. That is a common and reasonable setup. It is also a dependency worth knowing you have, because a DNS problem in the parent zone takes the status page name with it once cached answers expire.

Your checks run from inside your own stack

This is the case where the status page would be green even if it updated itself instantly. On 21 September 2026 GitLab posted an incident at 12:10 UTC: "We're experiencing degraded package, artifact, and registry download speed in APAC/Singapore region due to elevated CDN/Cloudflare latency." The 15:17 UTC update in GitLab's status history reads:

Cloudflare confirmed the traffic degradation was resolved, with recovery observed at approximately 13:40 UTC. Our application and backend checks remained healthy during the degradation, supporting that the impact was outside the GitLab application stack.

GitLab's page did show this incident, because people posted it. Read the second sentence as a design question instead: a page driven only by those application and backend checks would have stayed green for the whole degradation. For diagnosis, healthy internal checks are useful evidence that the problem is elsewhere. As a signal of what users in Singapore were experiencing, they said nothing, because those users reach GitLab through a CDN edge the checks never touch.

The AWS 2021 report shows the other version of the same problem in the sentence quoted above, whose first half reads: "The impairment to our monitoring systems delayed our understanding of this event". Monitoring that runs on the failing network fails with it. One way your checks stay healthy while users fail, the other way they go quiet. Neither turns the page red.

The fix for both is a signal that comes from where users are: outside your network, and from more than one location, since a check from a single region can be wrong for reasons unrelated to your site.

Nothing checks the part that broke

This one needs no incident report, since it follows directly from how a page is wired. Suppose the page has one component, "Website", fed by a monitor on the homepage. The payment provider behind checkout starts timing out. The homepage keeps returning 200 OK, the monitor passes, the status page stays green, and nobody can pay. The same happens with an API on its own subdomain, a login that fails only after the form is submitted, or one region behind a different CDN path. The uptime percentage built from that monitor stays at 100% too.

The page side of the same gap shows up in GitHub's analysis of its 21 October 2018 incident: "While many portions of GitHub were available throughout the incident, we were only able to set our status to green, yellow, and red." GitHub had the opposite symptom (red while many parts still worked), but the cause is shared: the page had no way to say which part users depend on was broken. Their stated fix was "displaying the different components of the platform so you know the status of each service".

Coverage comes from listing what users actually do, then giving each item a check that exercises it. A keyword check on a page that only renders when the backend answers covers more than a bare status code. An API health route that touches the database covers more than one that returns a constant.

Someone still has to post it

GitHub's 2018 timeline shows where the minutes go. The network partition happened at 22:52 UTC. At 22:54 UTC "Our internal monitoring systems began generating alerts indicating that our systems were experiencing numerous faults." The site went to yellow at 23:09 UTC, and the incident coordinator moved it to red at 23:13 UTC. That is 17 minutes from failure to the first public signal, and the responders were not idle: they were diagnosing database topologies and locking deploy tooling in between. The status page competes with the fix for the same people.

A backup posting path helps only if someone has used it. In the 2020 Kinesis event AWS had "a back-up means of updating the Service Health Dashboard that has minimal service dependencies", and it worked, but "we encountered several delays during the earlier part of the event in posting to the Service Health Dashboard with this tool, as it is a more manual and less familiar tool for our support operators." Their follow-up was training support engineers on it regularly.

Look at what triggers the post, too. GitLab's first update for its 503 errors on 24 September 2026 went out at 23:02 UTC: "We are recieving reports of 503 errors on GitLab.com." (spelling as published). The trigger named there is user reports. When customers are the detector, the page cannot go red before customers have hit the error, however quickly the human posts.

Why automating the whole page is the wrong fix

The popular answer to human lag is to take the human out and let monitoring flip the page on its own. The diagnosis is right; the GitHub timeline shows the lag is real. The remedy depends entirely on what feeds the automation. Wire the page to internal health checks and the GitLab Singapore case becomes a page that is green for the entire degradation, updated in real time. That trades a slow but honest page for a fast but blind one.

Automation fed by external checks is better, and it has its own cost: one flaky probe now flips a public page red, and a false alarm in front of customers does more damage than one in a team channel. Even Atlassian, which sells a status page product, writes in its guidance on automating Statuspage: "As a best practice, we never recommend fully automating your status page."

What works better: external checks from several locations, covering the paths users depend on, open the incident and alert a human, and that human publishes. Keep a prewritten "Investigating" message so publishing takes a minute rather than a drafting session. You keep a few minutes of human delay. External checks also miss things they cannot see, like a growing job queue or wrong data served with a 200, so internal signals and support tickets still matter. They inform the person posting; they should not be the only thing that decides what the page says.

The external part is what a tool like WebPixie's uptime monitoring covers: checks from multiple global locations, verification from other locations before an incident opens on paid plans, and alerts by email, Slack or webhook depending on your plan. Add the status page URL itself as one of the monitored targets, since Cloudflare's case shows the page can be the thing that is down.

Check your own status page setup

Five questions, each mapped to one of the failures above:

1. What feeds the page? If the honest answer is internal health checks, you have the GitLab Singapore gap. If a person who is also fixing the outage has to post it, you have the GitHub 17 minutes.
2. What does it cover? Write down what users do (sign in, pay, call the API, load the app from each region you serve) and match each to a check. Every unmatched line is a way to stay green during an outage.
3. Where does it live, and where does its name resolve? Run dig +noall +answer status.yourdomain.com and dig +short NS yourdomain.com. Note every provider in the chain that your main product also depends on.
4. Who can post when your main tooling is down? If posting needs a login through your own identity provider or SSO, that is the AWS 2020 Cognito setup. Keep a separate login and use the backup path on a schedule, not for the first time mid-incident.
5. Is the page itself checked from outside? If it goes down during your outage, responders lose time on it, as Cloudflare did, and customers see nothing at all.