Comment by goronbjorn | Hacker News Reader

Comment by goronbjorn | Hacker News Reader

Parent Full thread

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.

We're currently authoring an API and have a built an extremely crude reporting page showing endpoint response times by method.

https://sandbox.microco.sm/api/debug/slow?method=GET

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?

Great suggestions:

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.

Reply on news.ycombinator.com