3 ms·
If it's on a different domain and servers, I don't think it will be an issue. If they have it on an API call to (making it up) api.slack.com/status it might ve
by can16358p 5y ago
If it's on a different domain and servers, I don't think it will be an issue.
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.
- zht 5y agothis sounds very complicated lol
- sharklazer 5y agoNo, not really. If your calls time out, ping the status server. Done. It sounds more like laziness than complication to me. But that typifies Slack dev culture—“just use duct tape”
- Linkd 5y agoAnd that's exactly how you DDOS your status server.
- matthew-wegner 5y agoWhy can't they put a status.json file on S3/CloudFront/R2/wherever? And in an absolute worst-case infra collapse, someone there could manually edit/upload a new one...
- charcircuit 5y agoPut a CDN in front of the status server. If that overwhelms your CDN then add some exponential back off to the mix.
- can16358p 5y agoInitial setup is not much different than creating a new website, rest is trivial in practice. Easier than said.