7 ms·

Show HN: Built a self hosted clean status page and batteries

187 points by purple_wow 3y ago

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

rudasn 3y ago
Looks like this works without javascript enabled. Thanks! :)
- purple_wow 3y ago
  Well the initial load will work, but switching to Day Data will not work :(
cybrox 3y ago
This seems very nice and clean, I like it! 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?
- yellowsir 3y ago
  Well of course, there can still be bugs in the code even if 200 is returned. 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.
wscourge 3y ago
There's a whole red bar when the website was down for 1 minute on a given day. I don't like it, and I wouldn't want to show that to my users. I'd suggest you make the bar 1/3600 red, if the downtime was 1min - not exactly this, but you know what I mean.
- purple_wow 3y ago
  Interesting. May be I can add a gradient from red -> yellow -> green with effected minute count, normalized to gradient threshold percentage. Let me try doing that
  - 8organicbits 3y ago
    I think it's worth deciding what you want to communicate. If it's "we have good uptime, but we may lie", then it's a green bar always. If it's "we're honest about our downtime" then the colors should be distinct so users can notice and inspect the days that are <100%. A gradient runs the risk of looking "all green" even when some downtime minimal happened. If that's not the goal, then I'd recommend a step function (green, yellow, red, for example).
  - Tempest1981 3y ago
    Dynamic? A 1 minute outage in the last 60 min seems more red-color-worthy than a 1 minute outage a few days ago.
Daviey 3y ago
For personal monitoring, I've been using Uptime Kuma (and been happy with it). Has anyone looked how these two compare?
- ehaughee 3y ago
  I've been looking for a good and ideally very simple place to host an Uptime Kuma container with persistent storage. Any suggestions?
ahmedfromtunis 3y ago
I might be mistaken, but I always thought that status pages are supposed to be hosted by a third party. 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?
- Daviey 3y ago
  It entirely depends on your reason and expectation of the service. Yes, it would be best to separately host it on entirely different infra. However, if you have 1 x server, and you want to check that the services it is running are functional (such as a web server, app and database are functional), then co-locating this on there would be ok, providing the server itself doesn't go AWOL. However, running this on a dedicated virtual server or raspberry pi would likely be always better.
- purple_wow 3y ago
  In case of status page you would want to host it in a different server / zone.
ushakov 3y ago
[flagged]
- dewey 3y ago
  It's a small project with a clear and limited scope which makes it a good "hello world" project for developers. Just like we have a good selection of static site generators and blog frameworks used by one person only, nothing wrong with that. In the end what makes a status page successful isn't the code of the status page itself, but the reliability, the integration with existing tools (PagerDuty etc.) and all the checkboxes needed to sell to bigger companies.
  - purple_wow 3y ago
    Absolutely agree. I would be adding webhook integration with custom data transformation for popular providers like Slack/PagerDuty/Discord etc Thanks for pointing this out
- rozenmd 3y ago
  I got similar comments when I launched OnlineOrNot. My paying customers say there was indeed a need for a 200th uptime monitoring/status page service.
- risyachka 3y ago
  Considering 99% of existing software is pure crap - we need a lot more.
- plagiarist 3y ago
  As many as people want to make.
- deleted 3y ago
  [deleted]
75w 3y ago
What does ‘batteries’ mean in this instance?
- milliams 3y ago
  "features"
  - patja 3y ago
    The phrase is usually "batteries included" not "and batteries"
    - pricechild 3y ago
      And I'd disagree that "batteries included" is a phrase used to describe "features"? 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!
      - myself248 3y ago
        Seriously, I was so confused by this title. Batteries are necessary for basic function of a battery-powered device, they're not bells and whistles.
        karolist 3y ago
        I'm pretty sure this phrase in tech circles was popularized by Python's moto [1], which meant to say that language ships with many features you'd have to get on your own otherwise, so to me the phrasing here was clear - you will likely not need to pull in external deps to make it useable. 1. https://peps.python.org/pep-0206/ https://peps.python.org/pep-0206/
rustdesk 3y ago
I love https://github.com/upptime/upptime https://github.com/upptime/upptime, you run your uptime page on github.
- xtracto 3y ago
  This is amazing. Definitely will use it. Thanks for sharing
  - tibozaurus 3y ago
    At OpenStatus we also provide a self hosted status page on Cloudflare Pages https://github.com/openstatusHQ/astro-status-page https://github.com/openstatusHQ/astro-status-page
    - djbusby 3y ago
      I'm using a DIY status page tool. We publish ours as static HTML, no JS and hosted via Netlify
- madeofpalk 3y ago
  > you run your uptime page on github. Given the uptime of Github (especially Github Actions) this seems like a particuarly poor choice for an uptime tool.
ChrisMLane 3y ago
This looks great! 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.
corobo 3y ago
> Earth. Our blue planet. > No active incidents Typical status page, always showing green despite obvious issues :P
browningstreet 3y ago
What’s with “and batteries”? Doesn’t even get mentioned in the features list. Makes this feel AI generated and doesn’t clarify anything.
- js2 3y ago
  Probably an attempt at "batteries included" as in it comes with everything you need to start using it. https://news.ycombinator.com/item?id=39101910 https://news.ycombinator.com/item?id=39101910
  - deleted 3y ago
    [deleted]
- foobarbecue 3y ago
  Indeed. I was expecting one of those "server is a Raspberry Pi running on a solar panel in a cornfield" posts but this time it was hosting status pages.
- deleted 3y ago
  [deleted]
MaxGabriel 3y ago
> Kener is a Open-Source Should this be “an” in the page header?
lnxg33k1 3y ago
I think the incident.svelte file could use some love, is it best practice to put part of the phrase somewhere else? Doesn't it increase the cognitive stress? Like there is somewhere a phrase, but part of the text is being calculated https://github.com/rajnandan1/kener/blob/74ea57d6bbf6ac4dd3e9280bd8829fdcdb680d61/src/lib/components/incident.svelte#L33 https://github.com/rajnandan1/kener/blob/74ea57d6bbf6ac4dd3e... 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
renewiltord 3y ago
There's an "awesome status pages" list GitHub repo that lists a bunch of these. One thing I was wondering if anyone has a manual one? I could use one of these but I don't want any automation. Just a manual status page updater. Could even be a static site generator with helper scripts.
redleader55 3y ago
In 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 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.
- azornathogron 3y ago
  > 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.
- TheAdamist 3y ago
  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.
  - hypeatei 3y ago
    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?
    - 3y ago
mikecoles 3y ago
I checked out the top level pages. Looks slick. Congrats!
bearjaws 3y ago
Just 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...
- dirigeant 3y ago
  This is a common mistake until the first incident. Even AWS did it. Static files in their status page were hosted on S3 and when they had a fat-finger issue, their status page went down as well.
andy_ppp 3y ago
Looks really great, I need web sockets and token generation to be able to use it for https://veloa.com https://veloa.com
otteromkram 3y ago
Nice! Love seeing Svelte getting some attention. Such a great and underutilized framework in a world run by React/Vue/Angular.
darrenBaldwin03 3y ago
This is cool! OpenStatus (https://www.openstatus.dev/ https://www.openstatus.dev/) is another project thats aiming for something similar

187 points by purple_wow 3y ago

rudasn 3y ago

Looks like this works without javascript enabled. Thanks! :)

purple_wow 3y ago
Well the initial load will work, but switching to Day Data will not work :(

cybrox 3y ago

This seems very nice and clean, I like it! 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?

yellowsir 3y ago
Well of course, there can still be bugs in the code even if 200 is returned. 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.

wscourge 3y ago

There's a whole red bar when the website was down for 1 minute on a given day. I don't like it, and I wouldn't want to show that to my users. I'd suggest you make the bar 1/3600 red, if the downtime was 1min - not exactly this, but you know what I mean.

purple_wow 3y ago
Interesting. May be I can add a gradient from red -> yellow -> green with effected minute count, normalized to gradient threshold percentage. Let me try doing that
- 8organicbits 3y ago
  I think it's worth deciding what you want to communicate. If it's "we have good uptime, but we may lie", then it's a green bar always. If it's "we're honest about our downtime" then the colors should be distinct so users can notice and inspect the days that are <100%. A gradient runs the risk of looking "all green" even when some downtime minimal happened. If that's not the goal, then I'd recommend a step function (green, yellow, red, for example).
- Tempest1981 3y ago
  Dynamic? A 1 minute outage in the last 60 min seems more red-color-worthy than a 1 minute outage a few days ago.

Daviey 3y ago

For personal monitoring, I've been using Uptime Kuma (and been happy with it). Has anyone looked how these two compare?

ehaughee 3y ago
I've been looking for a good and ideally very simple place to host an Uptime Kuma container with persistent storage. Any suggestions?

ahmedfromtunis 3y ago

I might be mistaken, but I always thought that status pages are supposed to be hosted by a third party. 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?

Daviey 3y ago
It entirely depends on your reason and expectation of the service. Yes, it would be best to separately host it on entirely different infra. However, if you have 1 x server, and you want to check that the services it is running are functional (such as a web server, app and database are functional), then co-locating this on there would be ok, providing the server itself doesn't go AWOL. However, running this on a dedicated virtual server or raspberry pi would likely be always better.
purple_wow 3y ago
In case of status page you would want to host it in a different server / zone.

ushakov 3y ago

[flagged]

dewey 3y ago
It's a small project with a clear and limited scope which makes it a good "hello world" project for developers. Just like we have a good selection of static site generators and blog frameworks used by one person only, nothing wrong with that. In the end what makes a status page successful isn't the code of the status page itself, but the reliability, the integration with existing tools (PagerDuty etc.) and all the checkboxes needed to sell to bigger companies.
- purple_wow 3y ago
  Absolutely agree. I would be adding webhook integration with custom data transformation for popular providers like Slack/PagerDuty/Discord etc Thanks for pointing this out
rozenmd 3y ago
I got similar comments when I launched OnlineOrNot. My paying customers say there was indeed a need for a 200th uptime monitoring/status page service.
risyachka 3y ago
Considering 99% of existing software is pure crap - we need a lot more.
plagiarist 3y ago
As many as people want to make.
deleted 3y ago
[deleted]

75w 3y ago

What does ‘batteries’ mean in this instance?

milliams 3y ago
"features"
- patja 3y ago
  The phrase is usually "batteries included" not "and batteries"
  - pricechild 3y ago
    And I'd disagree that "batteries included" is a phrase used to describe "features"? 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!
    - myself248 3y ago
      Seriously, I was so confused by this title. Batteries are necessary for basic function of a battery-powered device, they're not bells and whistles.
      - karolist 3y ago
        I'm pretty sure this phrase in tech circles was popularized by Python's moto [1], which meant to say that language ships with many features you'd have to get on your own otherwise, so to me the phrasing here was clear - you will likely not need to pull in external deps to make it useable. 1. https://peps.python.org/pep-0206/ https://peps.python.org/pep-0206/

rustdesk 3y ago

I love https://github.com/upptime/upptime https://github.com/upptime/upptime, you run your uptime page on github.

xtracto 3y ago
This is amazing. Definitely will use it. Thanks for sharing
- tibozaurus 3y ago
  At OpenStatus we also provide a self hosted status page on Cloudflare Pages https://github.com/openstatusHQ/astro-status-page https://github.com/openstatusHQ/astro-status-page
  - djbusby 3y ago
    I'm using a DIY status page tool. We publish ours as static HTML, no JS and hosted via Netlify
madeofpalk 3y ago
> you run your uptime page on github. Given the uptime of Github (especially Github Actions) this seems like a particuarly poor choice for an uptime tool.

ChrisMLane 3y ago

This looks great! 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.

corobo 3y ago

> Earth. Our blue planet. > No active incidents Typical status page, always showing green despite obvious issues :P

browningstreet 3y ago

What’s with “and batteries”? Doesn’t even get mentioned in the features list. Makes this feel AI generated and doesn’t clarify anything.

js2 3y ago
Probably an attempt at "batteries included" as in it comes with everything you need to start using it. https://news.ycombinator.com/item?id=39101910 https://news.ycombinator.com/item?id=39101910
- deleted 3y ago
  [deleted]
foobarbecue 3y ago
Indeed. I was expecting one of those "server is a Raspberry Pi running on a solar panel in a cornfield" posts but this time it was hosting status pages.
deleted 3y ago
[deleted]

MaxGabriel 3y ago

> Kener is a Open-Source Should this be “an” in the page header?

lnxg33k1 3y ago

I think the incident.svelte file could use some love, is it best practice to put part of the phrase somewhere else? Doesn't it increase the cognitive stress? Like there is somewhere a phrase, but part of the text is being calculated https://github.com/rajnandan1/kener/blob/74ea57d6bbf6ac4dd3e9280bd8829fdcdb680d61/src/lib/components/incident.svelte#L33 https://github.com/rajnandan1/kener/blob/74ea57d6bbf6ac4dd3e... 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

renewiltord 3y ago

There's an "awesome status pages" list GitHub repo that lists a bunch of these. One thing I was wondering if anyone has a manual one? I could use one of these but I don't want any automation. Just a manual status page updater. Could even be a static site generator with helper scripts.

redleader55 3y ago

In 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 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.

azornathogron 3y ago
> 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.
TheAdamist 3y ago
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.
- hypeatei 3y ago
  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?
  - 3y ago

mikecoles 3y ago

I checked out the top level pages. Looks slick. Congrats!

bearjaws 3y ago

Just 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...

dirigeant 3y ago
This is a common mistake until the first incident. Even AWS did it. Static files in their status page were hosted on S3 and when they had a fat-finger issue, their status page went down as well.

andy_ppp 3y ago

Looks really great, I need web sockets and token generation to be able to use it for https://veloa.com https://veloa.com

otteromkram 3y ago

Nice! Love seeing Svelte getting some attention. Such a great and underutilized framework in a world run by React/Vue/Angular.

darrenBaldwin03 3y ago

This is cool! OpenStatus (https://www.openstatus.dev/ https://www.openstatus.dev/) is another project thats aiming for something similar