I love the 3 big icons/images for status. That's what people want to see when they first come to the page.I also love the columns for twitter comments paired with yellow<->red spectrum of when there was trouble.
However, don't default to grey, default to green if nothing went wrong. :+1: otherwise.
The page is driven via the @balancedstatus Twitter account via a protocol our CEO, Matin, came up with. Here's the relevant section from the README for the repo:
## Message Display Behavior
Messages are fed into the system via the @balancedstatus Twitter account.
Messages take the format
`<SYSTEM>-<STATE>: <MESSAGE>`; e.g.
* `DASH-UP: Everything is back to normal`
* `API-ISSUE: We are experiencing problems`
* `JS: Here's an informal message` _(non-error message)_
Where STATE is one of `UP`, `DOWN`, `ISSUE`
Messages with a state are displayed in the lower portion of the page idefinitely, `ISSUE` or `DOWN` messages will change the icon of the corresponding service. These messages must be followed by an `UP` state message in order to revert the displayed icon to its natural state.
Messages without a state are displayed in the upper middle portion of the page for 24 hours.
/----------------------------------------------
Beyond that we parse and feed our logs from the various services that make up the Balanced stack and then calculate the uptime percentages based on number of 500s (and slow requests) / non-500s.
This is very good! I work for a payments service provider in India. And at our company, we have something similar but not so detailed as this. Ours is built on top of Pingdom - http://status.juspay.in/.
The bottomline here is that transparency is a virtue. And this is something that is all the more important for a company operating in the payments industry.
15 comments
[ 5.0 ms ] story [ 18.4 ms ] threadHowever, don't default to grey, default to green if nothing went wrong. :+1: otherwise.
## Message Display Behavior
Messages are fed into the system via the @balancedstatus Twitter account.
Messages take the format
`<SYSTEM>-<STATE>: <MESSAGE>`; e.g.
* `DASH-UP: Everything is back to normal` * `API-ISSUE: We are experiencing problems` * `JS: Here's an informal message` _(non-error message)_
Where STATE is one of `UP`, `DOWN`, `ISSUE`
Messages with a state are displayed in the lower portion of the page idefinitely, `ISSUE` or `DOWN` messages will change the icon of the corresponding service. These messages must be followed by an `UP` state message in order to revert the displayed icon to its natural state.
Messages without a state are displayed in the upper middle portion of the page for 24 hours.
/----------------------------------------------
Beyond that we parse and feed our logs from the various services that make up the Balanced stack and then calculate the uptime percentages based on number of 500s (and slow requests) / non-500s.
Shouldn't it be (# of 500s)/(# of 500s + # non-500s)?
I assume of course, 500 is the HTTP status codes
Other than that, brilliant beautiful page.
That's actually how it's calculated :)
I think mjallday had a typo. His anti procrastination settings are turned on so he can't make an edit to his comment :P
Happy to talk more about how this works, why we decided to take this approach and how we constitute 500s as down time.
I can also discuss our extensive automated testing and how it's conducted across all our services to provide transparency to our customers.
https://status.heroku.com/ http://blog.heroku.com/archives/2012/8/6/design_of_the_statu...
The bottomline here is that transparency is a virtue. And this is something that is all the more important for a company operating in the payments industry.
Once we used HTML TABLEs to express everything, and accessibility was destroyed by the many nested tables used to define layout.
But now we use DIV and UL to express tabular data, and accessibility is destroyed by the many nested divs and lists that define a table.
Would love to have seen a status page with highly accessible HTML still look as beautiful as this one does.