Wouldn't that be an anti-feature?
When Slack is down, Slack can't tell you when it is down. It's why status pages are often on other domains/systems etc, so the status page remains up while everything else is on fire.
When Slack is down, Slack can't tell you when it is down. It's why status pages are often on other domains/systems etc, so the status page remains up while everything else is on fire.
If they have it on an API call to (making it up) api.slack.com/status it might very well go down when things go wrong, making it useless.
However if they physically host it elsewhere ideally on a different cloud provider, with a different domain, say, slackstatus.com/api-status that is completely separate from the actual services, which can both query the actual service with a call from outside and can be updated manually with physical persons at Slack, and the client checks that domain, I think it can work.
It sounds more like laziness than complication to me. But that typifies Slack dev culture—“just use duct tape”
And in an absolute worst-case infra collapse, someone there could manually edit/upload a new one...