Show HN: Host your status page on GitHub | Hacker News Reader

Show HN: Host your status page on GitHub

github.com

248 pointsjayfk43 comments

I use Github Pages for my status page too.

Not something I use for websites/web apps I develop for clients, but for my own irrelevant website, I go as far as to cheat and use the following:

    <img src="https://des.tination.server/img/1px.gif" 
         onload="statusOk()"
         onerror="statusDown()" 
         alt="">

    <script>

      function statusOk()
      {
        // do something involving green and check marks
      }

      function statusDown()
      {
        // do something involving red... and crosses
      }

    </script>

(Obviously you have to prevent caching)

People usually don't go to a status page to see if a page is reachable from their computer. They know that already. They want to know if it's a global issue, and if the company is aware that it's down, and when it will be back up.

good point, in our situation people check to see if the mail server is down etc

for more complex usecases you could load an api status json endpoint instead

You could also poll the Github API direclty on the client side via Javascript/jQuery (without giving the client an access token obviously) to display the status information, like that you could simply update issues on a public Github repo and the information would change accordingly on the site. With proper E-Tag checking, Github won't even count repeated API queries against the rate limit, which means that you could have the client automatically update the information in the frontend every few seconds.

With Gitboard I use the Github API in this way to display issues in a Kanban board, which works really nicely: https://adewes.github.io/gitboard

Very cool idea!

> ... With proper E-Tag checking, Github won't even count repeated API queries against the rate limit ...

Does this behavior rely only on the browser side? Did you add something in javascript?

You need to pass the ETag header in the Ajax request, though jQuery might do this automatically (have a look at the utils.js in Gitboard: http://github.com/adewes/gitboard). As long as you set it and the data is unchanged you can poll for it as often as you want, which us perfect to watch for changes.

Thank you a lot!

I missed that part:

https://developer.github.com/v3/#conditional-requests

"Also note: making a conditional request and receiving a 304 response does not count against your Rate Limit, so we encourage you to use it whenever possible."

jQuery doesn't automatically attach the ETag, but the browser does.

So etags should work with JSONP call...

I found that:

http://fitzgen.github.io/github-api/

I think you don't even need JSONP, just make sure to set the cross-domain headers and it should work.

Github recently is more offline than my Servers. Not sure if that would really help.

At the exact same time, too?

Well given the amount both are offline recently, it could have happened.

Keep in mind this is at its core just a static site generator, there's nothing stopping you from pushing the generated site to S3, or even just a random server, and hosting it there instead if you don't like Github's uptime.

There is one thing. Updates to S3 files are not atomic. That is, if you update a file, you may still get an old version of it for a time. Same with deletes. The only atomic operation it supports is creating a new object.

I'm not sure you mean atomic, unless you've seen cases where the file you get from S3 is a mix of the old and new version. Did you mean consistent (which is what you describe)?

If you update index.html and style.css, GitHub pages will apparently publish them simultaneously (atomically), but with S3 you upload index.html, then style.css — one of them will be "published" later than the other.

(Analogy: GitHub pages is like creating a new directory, putting files there, then renaming the directory to the old name; S3 — putting files into the old directory.)

I do mean atomic, as a concept that includes durability and consistency. From Wikipedia:

> An atomic transaction is an indivisible and irreducible series of database operations such that either all occur, or nothing occurs. A guarantee of atomicity prevents updates to the database occurring only partially, which can cause greater problems than rejecting the whole series outright.

That is, if I update index.html on S3, only some of their actual servers get the update right away, and some do no. Thus if I start downloading index.html from different parts of the world I will see either the old or the new version.

Atomic does not necessarily imply multiple actions being bundled together, which is what you may be thinking of. For example the mv command on Linux is atomic: it renames a file and returns once the rename is complete. This is not the case with S3.

Another way to think of it: atomic update to all the S3 servers at once instead of to just some of them.

I think he meant automatic.

Absolutely. Once the site is generated, you want to push the following files:

- index.html - style.css - milligram.min.css

and, if you need the logo/favicon

- favicon.png - logo.png

Personally I prefer a service like http://status.io - it's one less thing I need to maintain/etc.

Not to mention GitHub has had more than its fair share of outages.

Wow...

This looks very similar to Cachet [1]. Did you take inspiration from it?

[1] https://cachethq.io

Not specifically.

If you take a look at statuspage.io [1], status.io [2] or cachet [3] they look more or less the same.

[1] https://www.statuspage.io/ [2] https://status.io/ [3] https://cachethq.io/

Anyway, it's a clever idea but GitHub itself suffers a lot of outages. Is this a good idea?

99.9% uptime for the last month [1] doesn't qualify as "a lot of outages" in my opinion.

[1]: https://status.github.com/graphs/past_month

They seem to be a significant target for DDOS attacks, which seem to have been quite frequent.

That uptime measure is for the application server, which I suspect does not include GitHub Pages which is hosted separately on static content servers.

Lastly, 99.9% uptime over a month means 43 minutes of downtime. To me, that sounds like quite a lot.

The likelyhood that you have downtime at the exact same time GitHub does is fairly low though.

I find 43 minutes of outage in one month for a well paid service a bit much

AFAIK they have sharded their pages and repositories in a way that if one gets DDoS, usually it's only that piece that gets downtime (I know this because there was a problem with the Chinese government and a Github repo, that got constantly attacked, but that was the only repo suffering).

Ofcourse, if one does a sharding, it's bound not to be repo by repo, so there might be adjacent ones suffering. But I use GH everyday, can't remember a time when it was offline.

Here is the confirmation of such a mechanism (they simply rate limit certain repos):

"All of these factors combine to make CocoaPods/Specs one of the top five most resource-costly repositories that we host on all of GitHub.com. And that is why it is rate-limited; otherwise it would consume even more resources and cause service interruptions for other GitHub users. The symptoms of the rate limiting for you and your users are that your repository accesses (clones, fetches, pushes) have to wait in a queue on our end, sometimes for a long time, before being processed. This causes fetches/clones to take much longer than they would otherwise, and might cause timeouts at your end. Moreover, if the load on our servers becomes too overwhelming, a fraction of the accesses might be rejected altogether."

From: https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm...

Are there any decent open source status page systems that do the monitoring for you? I'm just looking for a basic ping or JSON response to automatically update the page for me. I'd like for the page to show there's a problem before I manually work it out for myself!

If you install Cachet [1] you can install Cachet Monitor [2] which can monitor URLs for you!

[1] https://cachethq.io

[2] https://github.com/castawaylabs/cachet-monitor

Nice, thank you!

But seriously - statuspage.io is amazing for this and super cheap.

StatusPage.io is nice but they charge $99/mo for custom CSS and $399/mo for custom HTML. I don't see that as being cheap.

StatusPage.io is far from cheap for most bootstrapped SMB's or services. That's why I built Cachet [1]

[1] https://cachethq.io

I built a static status page that you can host anywhere. I use it for various systems. Its ugly, but works as required. Uses bootstrap and jquery. so you can go crazy with it. Everything is self contained. No need to maintain it. Does need an endpoint for the status page to ping. YMMV.

https://github.com/bliti/status-page

And here it is a follow-up post with some shared experience: https://medium.com/@stanbright/how-to-set-up-a-free-status-p...

Nice "hack". I'm using statuspage.io for the notification side of things but can see why this is a very decent free alternative.

Host my status page on a site that is down about half the time? Hah

0.0899% == half

Yeah, that's several orders of magnitude closer to half than I expect it to be.

Reply on news.ycombinator.com