I checked out the top level pages. Looks slick. Congrats!
Show HN: Built a self hosted clean status page and batteries
41–50 of 56 posts
Re: Show HN: Built a self hosted clean status page and batteries
#42Just make sure to host it on some other hosting provider. If you're on AWS, use GCP or Azure, etc..
A previous DevOps team I worked with brilliantly centralized everything into K8s, including the status page software. Then pushed a K8s update that broke everything...
Re: Show HN: Built a self hosted clean status page and batteries
#43Looks really great, I need web sockets and token generation to be able to use it for https://veloa.com
Re: Show HN: Built a self hosted clean status page and batteries
#44Nice! Love seeing Svelte getting some attention. Such a great and underutilized framework in a world run by React/Vue/Angular.
Re: Show HN: Built a self hosted clean status page and batteries
#45In my view, a status page should have only one function: communicate to your users if your service is up, how long has it been down, and which parts are down and maybe list work that you do fix the issues. Updating it should be done, automatically and as simple as possible, as part of incident response process. A status page should not replace your internal monitoring, so including "batteries" is both not necessary a…
> A status page should not have dependencies, and if it does, they should have higher availability than your service.
IMHO this is often unnecessary. The critical thing is for the failure modes of your status page to be uncorrelated with the failure modes of your service, so that you're unlikely to break both at the same time. But you might have, eg, some public API with a 99.995% availability target, and a status page with a 99.95% target - it of course depends on your situation but those numbers wouldn't strike me as being intrinsically wrong as long as the status page is properly independent of your service.
Re: Show HN: Built a self hosted clean status page and batteries
#46In my view, a status page should have only one function: communicate to your users if your service is up, how long has it been down, and which parts are down and maybe list work that you do fix the issues. Updating it should be done, automatically and as simple as possible, as part of incident response process. A status page should not replace your internal monitoring, so including "batteries" is both not necessary a…
It should be timely as well, reddits status page will happily show all green while down detector for reddit shows huge spikes in error reporting.
Which doesn't make for a super useful status page.
Re: Show HN: Built a self hosted clean status page and batteries
#47In my view, a status page should have only one function: communicate to your users if your service is up, how long has it been down, and which parts are down and maybe list work that you do fix the issues. Updating it should be done, automatically and as simple as possible, as part of incident response process. A status page should not replace your internal monitoring, so including "batteries" is both not necessary a…
> Node.js sounds like a liability in this case.
that depends on what types of dependencies you're talking about
if you're talking about upstream servers/services, yep absolutely
but node.js dependencies (as in, libraries and packages), don't magically update by themselves. there's no reason node.js is a liability here unless you coordinate updating your service and status page dependencies at exactly the same time (which seems.. idiotic?)
Re: Show HN: Built a self hosted clean status page and batteries
#48In my view, a status page should have only one function: communicate to your users if your service is up, how long has it been down, and which parts are down and maybe list work that you do fix the issues. Updating it should be done, automatically and as simple as possible, as part of incident response process. A status page should not replace your internal monitoring, so including "batteries" is both not necessary a…
It should be timely as well, reddits status page will happily show all green while down detector for reddit shows huge spikes in error reporting. Which doesn't make for a super useful status page.
I don't really know what people expect with status pages. Having it change automatically based on metrics can result in inaccurate status. Having it behind a manual gate can be inaccurate since that takes time with approvals and such.
So, what exactly is the expectation and how can you implement a perfect status system?
Re: Show HN: Built a self hosted clean status page and batteries
#49In my view, a status page should have only one function: communicate to your users if your service is up, how long has it been down, and which parts are down and maybe list work that you do fix the issues. Updating it should be done, automatically and as simple as possible, as part of incident response process. A status page should not replace your internal monitoring, so including "batteries" is both not necessary a…
This is actually a fair point. The batteries in this case are nice to haves, but to be fair I personally would not be using this as infrastructure frontline status reporting.. more so for a client/customer facing status feedback.
Re: Show HN: Built a self hosted clean status page and batteries
#50Earlier quoted context omitted.
It should be timely as well, reddits status page will happily show all green while down detector for reddit shows huge spikes in error reporting. Which doesn't make for a super useful status page.
I don't really know what people expect with status pages. Having it change automatically based on metrics can result in inaccurate status. Having it behind a manual gate can be inaccurate since that takes time with approvals and such. So, what exactly is the expectation and how can you implement a perfect status system?
> Having it change automatically based on metrics can result in inaccurate status.
A status pages job is to inform users about potential issues. A user will seek out the status page specifically if they currently see issues on their end, but usually won't if they don't. Therefore underreporting is a huge issue, because you essentially tell your users that the issue must be on their end even if it is not, but overreporting issues when there are none hurts no one and the chances are high that no user even sees it.