3 ms·
This looks pretty neat. Congratulations on your launch! Looks like it also monitors uptime, which feels like a more feature-rich alternative to Pingdom, which
by jonaf 10y ago
This looks pretty neat. Congratulations on your launch!
Looks like it also monitors uptime, which feels like a more feature-rich alternative to Pingdom, which just checks for HTTP 200 responses.
I'm not sure I understand why the focus on "production APIs," except that they're more easily accessible from the internet. I would expect many enterprises would love to be able to run this in their own private data center, sort of like an on-premise solution, against staging API's or pre-release API's. Why focus all the marketing on "production," though? Isn't it just putting test data in production? How is this better than putting the same test data in QA and testing before you release to production?
- CodyReichert 10y agoHey, thanks for checking it out! Glad you were able to see the usefulness of it :) I agree that staging/pre-release testing is really valuable. We want to make sure those uses-cases are supported and just as easy, ideally hooking into CI, code deploy, etc. I'll have to think about how I can re-word this a bit. If a staging site or internal service isn't behind some firewall it will already work; I'll make that more clear as we add better support for these workflows. Good points. Monitoring uptime of any endpoint is really easy to set up! Just type it in and set a schedule. 200's are default, but you can set any status code. For me personally, I like to set up a lot of tests for 'admin-only' endpoints (eg, asserting that unauthorized requests are denied). And I agree, that's a big improvement over some of the more basic monitoring tools. Thanks again for the feedback. We're hoping to add some more assertions this weekend, so check back up in a couple days!