We've had a few requests on HN about releasing this info, so we did it. Some more information is available on the introduction blog post: https://zapier.com/blog/2013/05/06/introducing-api-status-bo... We also provide an RSS feed and JSON API to access this data.
I'll watch this thread all day and answer questions, as well as field requests. This is for you guys, so if we're missing something vital, let us know and we'll get on it.
Wow this is great! I was literally working on something just like this last week.
A couple of things I found to be of value in my project that you might find helpful:
1) Endpoint-level granularity
A lof of APIs are RESTful these days, and the trend is for more to be that way than not. It would be nice to see (optionally) the uptime broken out by resource for that API. APIs generally connect to a bunch of different backend services on the API provider's side (think the difference between SMS and Voice with Twilio), and there's a high likelihood that one part could be down while the other is not (e.g. SMS is down for Twilio, but Voice is not).
2) Response Times
This is tricky because response times can be fickle for any number of reasons like network issues, for example. However, I've found that there is value in monitoring response times and big jumps (e.g. anything 1-2 standard deviations off the norm warrants an alert). What would be really cool is if you can monitor response times across various AWS regions.
The data on it isn't accurate at the moment as I keep runnning tests designed to flush caches and then re-request resources which skews the numbers.
I want this kind of data so that if I were a developer implementing against an API I would have real data to tell me what the expected response times for a HTTP method and endpoint.
When we get to producing an uptime page, I was thinking of treating uptime as a relative quality measure rather than a yes|no thing... if an endpoint responds in more than a couple of seconds then it's score might by 80%, and less than 50ms then it's 100%, and unresponsive or down would be 0%.
Question is: Is this kind of thing useful? Does anyone have a preferred format for this kind of data?
1) Some less popular endpoints have lower volume, so that would be a challenge to be sure of issues. However, we could probably aggregate the endpoints that are causing issues and attach them to the report. We'll look into that.
2) Response times are definitely of interest too, we don't track that now though. We'll think on that as well.
Not sure how well the site's font renders on other machines/browsers, but on Windows 7 Pro x64, Google Chrome 26.0.1410.64 m, your font renders with holes in it. Very odd.
Chrome's web font rendering on Windows is terrible (as is its high-DPI support and text color accuracy). It does this to virtually every custom font without super thick weight. I've opened bug reports since early 2012 that keep getting pushed back to the next milestone indefinitely. There's not much that can be done about it except use default fonts or accept that things will look kinda crappy on the largest browser/OS combination.
Seeing that you guys can integrate the Eve Online API into everything makes me smile ear to ear. I've gotta find a way to use you guys for something, just for coming up with that idea.
I would like to give a shout-out to Zapier as a tool for building production level systems. One of our production app's module is built completely on Zapier and it has worked really well till now.
One addition I would add would be to actually link to the service or their status page. If you are going to call them out if their service is down, at least give them something in return, i.e. discovery.
I'll watch this thread all day and answer questions, as well as field requests. This is for you guys, so if we're missing something vital, let us know and we'll get on it.