I've been building something like this for 12 years now.
One major difference is mine does not only rely on the "official" status page but also receive millions of reports from users about outages.
So your single pane of glass can show not just known outages but emerging ones that haven't been acknowledged yet by providers.
Also supports more than 8,000 services.
But then, the home page can be cached, and bots can be batched and nobody would ever notice the difference.
There is still a tendency within some parts of aviation (safety auditing) to look for root causes and use tools like "fish bone diagrams" despite the more holistic approach used after an actual crash or incident.
you're it does not.
> Most of these have no relation to each other other than the high level services on the cloud providers.
so, some of them are related to each other? some of them even share underlying infrastructure? perhaps multiple of these are considered infrastructure for some teams?
what is the point you're trying to make?
Does the size indicate anything?
And those are just the 2 that I checked.
To be fair, accurately scraping and normalizing data from status pages is really hard to to do consistently (my company has a team of 5 engineers to do it and it's a lot of work).
And what does it mean exactly?
I run an outage detection service - and some of these issues, like parsing hundreds of - sometimes undocumented - status APIs, make for an interesting engineering problem.
If you're drawing the data from a public resource like downdetector or using the sites status pages, then you may not be reflecting reality, but it should be clear what the provenance of the data is.
``` if(github) return false ```