Status pages have been the way they have seen the mid 2010s. There are few new ones but they are paid. So I decided to build this using svelte + sveltekit. It has all the necessary features. Few are yet to be built. Do check it out |
Status pages have been the way they have seen the mid 2010s. There are few new ones but they are paid. So I decided to build this using svelte + sveltekit. It has all the necessary features. Few are yet to be built. Do check it out |
A status page should not replace your internal monitoring, so including "batteries" is both not necessary and a bad idea - because of the next point.
A status page should not have dependencies, and if it does, they should have higher availability than your service. Otherwise, you need a status page for your status page. Node.js sounds like a liability in this case.
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.
Which doesn't make for a super useful status page.
So, what exactly is the expectation and how can you implement a perfect status system?
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?)
Given the uptime of Github (especially Github Actions) this seems like a particuarly poor choice for an uptime tool.
I'd suggest you make the bar 1/3600 red, if the downtime was 1min - not exactly this, but you know what I mean.
> No active incidents
Typical status page, always showing green despite obvious issues :P
A tangent: This style of status page and the goal that most of these projects (like this) try to achieve is always displaying the uptime of a service based on some HTTP request. In how many cases is this actually the whole story? GitHub can serve perfectly fine HTTP content, it's still broken without git via ssh. Amazon can have their site up but if payments aren't being processed, that's worth nothing.
This is not a complaint against this specific project but am I the only one that feels that this style of status page that "has been around since the mid 2010s" rarely ever tells the full story of a service's health?
I always implement a /~/healthcheck route which will return the exit code of each check, but also encodes it in the HTTP STATUS. if any error is detected the status will be 500 if any warning is detected it will be 200+<numberOfWarnings> of course checks still need to be written, e.g. a code needs to verify that it can connect to ssh and is greeded with the correct login msg.
still there could be problems for outcomming connections.
One thing I would like to see in the README is how this project differs from other popular similar projects such as "Upptime" which is already mentioned in the "Inspired from" section.
Isn't it easier to understand what is going on just by calculating the condition on the top and put the text on the markup based on that condition?
I feel like there are few places where in order to don't duplicate part of the text it's being made extremely difficult what the text is going to be by putting it far away
Am I supposed to have this run on a separate (presumably) dedicated server? Otherwise what's the point of having this running if it becomes inaccessible the instant my server goes down?
However, running this on a dedicated virtual server or raspberry pi would likely be always better.
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...
Should this be “an” in the page header?
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.
[1]: https://xpaw.me/
I would interpret "batteries included" to mean "you don't need to worry about shaving a yak to get this installed, it's all there and ready". Language is fun!