3 ms·
There seem to be two types of status-pages: Really great ones show that all services are up, and often have timing information, graphs, or metrics, etc. An ex
by stevekemp 9y ago
There seem to be two types of status-pages:
Really great ones show that all services are up, and often have timing information, graphs, or metrics, etc. An example of this would be https://status.bitbucket.org/ https://status.bitbucket.org/
More basic status-sites generally only show useful detail(s) if something is currently broken, and perhaps will show you a summary of recent problems over the past few days. An example of that would be https://status.github.com/messages https://status.github.com/messages
(I wrote a simple status-page for my own site, but I elected to go the simple route. I do monitor availability and response-time(s) of various parts of the service, but I only update the site when there are problems, manually. This works for me because problems are rare, and my site is small.)
- marknadal 9y agoThank you for these links! So... This still seems problematic though - if you manually update it, then the hash of the page is going to change, and then you'd need to retrieve a different IPFS item than the original status page. And so on... No? This just seems like an odd loop.
- stevekemp 9y agoWhen I manually update my site, that just means I add a file to the git-repository with today's date. Once I commit and push that a Makefile rebuilds my (static) site. I don't personally use IPFS, but I imagine if I did then I'd have a script to change DNS, or update the hash IPFS uses. I see from other replies that updating the "most recent" version of a site is simple enough that it shouldn't be a problem in practice.
- snissn 9y agoipfs works by creating a URL based on the hash of the content that you're publishing. so ipfs.io/hash(MYSITEISDOWN) vs ipfs.io/hash(MYSITEISUP)