TurboAPI

The quickest way to monitor your API and Webhook Performance

No Employees
Founders Code
Solo Founder
Analytics
APIs
Programming
SaaS

I was frustrated that the current set of API monitoring tools are too basic or too expensive, I created TurboAPI. There is no other tool on the market focused solely on performance and can track webhook performance.

November 18, 2020 Application Performance Stats

At TurboAPI's core is data, that's why I've launched a new performance stats page. On this page, you can gain instant insight into how well your application is performing.

Currently you can view the average response time, number of monitors that went above the performance budget you set as well as a graph plotting the performance of the application by the time of the day. This graph can give you insight into potential issues at certain times of the day. Why would this be? Potentially your app is used more at certain times of the day (e.g., a food delivery app at midday and evenings). This data can then see if your application is still performing acceptably at these "peak" usage times.

Enjoy! Josh https://turboapi.dev

October 24, 2020 Launch day

The last few bugs for the site were fixed and the site was shipped live!
I’m incredibly proud of launching a product but have loved the journey and struggle of getting it to market.
Now I need to market the product, which, in retrospect, I should have done more of during the build. Never mind, I think it’s a key takeaway of this process.

I’m going to create screencasts, tweets and reach out to coworkers (former and present) to propose the app to them and demo it.

Because I hope people will read this and want to learn what it takes to build a product, here are my personal key takeaways from the process

  • Marketing is part of building the product - don’t underestimate it
  • Use momentum when building products to build them faster
  • There is always a lot more features than your core USP - be mindful that you sometimes need to build “surrounding” features like authentication, payment flows etc.
  • No matter how much advise you read - it helps to experience it yourself
  • Enjoy the journey not the destination - if you don’t enjoy the building part of products then you’ll quickly burn out

These insights aren’t unique but I hope they help you on your journey

Please check it out here: https://TurboAPI.dev
If you tweet “I’m an indie hacker” to @TurboAPI on Twitter and follow the account then I’ll send you a free month code

October 24, 2020 Launch day

The last few bugs for the site were fixed and the site was shipped live!
I’m incredibly proud of launching a product but have loved the journey and struggle of getting it to market.
Now I need to market the product, which, in retrospect, I should have done more of during the build. Never mind, I think it’s a key takeaway of this process.

I’m going to create screencasts, tweets and reach out to coworkers (former and present) to propose the app to them and demo it.

Because I hope people will read this and want to learn what it takes to build a product, here are my personal key takeaways from the process

  • Marketing is part of building the product - don’t underestimate it
  • Use momentum when building products to build them faster
  • There is always a lot more features than your core USP - be mindful that you sometimes need to build “surrounding” features like authentication, payment flows etc.
  • No matter how much advise you read - it helps to experience it yourself
  • Enjoy the journey not the destination - if you don’t enjoy the building part of products then you’ll quickly burn out

These insights aren’t unique but I hope they help you on your journey

Please check it out here: https://TurboAPI.dev
If you tweet “I’m an indie hacker” to @TurboAPI on Twitter and follow the account then I’ll send you a free month code

September 11, 2020 Stripe Integration Done!

Long time since I gave an update! Loads has been done!

  • Stripe integration is now done - so the whole payment flow works end to end
  • Lots of new API endpoints to support stats that we want to display to the user
  • Added auth0 M2M token caching so we don't go over our quota!
  • Improved API resiliency
  • Added support for webhook tests

What's next?

  • Finish up the frontend
  • Do E2E tests
  • Launch!

Not long now! We are aiming for the 15th Oct as a launch date. See you then!

June 16, 2020 E2E Testing and Monitoring

Over the past few days, I've been pushing up the work that has been done recently to our production environment. I had to write an interesting serverless config that involved:

  • Creating multiple lambdas with SNS triggers
  • Creating those SNS topics based on the lambda names

Anyway, that got all sorted and that's deployed now!

I also deployed a new version of the API but ran into an issue where the UUID module would not run on Node 13 - so I've had to change down to Node 12 - which is probably for the best since it's LTS and the same as the lambda runtime.

I've now got to a stage where I can start dogfooding the app, so I've begun to perform end-to-end tests for the endpoint monitoring. I have ran into a few bugs and have been quickly squashing them and deploying new versions.

I need to create an example case for the webhook monitoring for testing purposes so I'll work on this soon. I hope to use this at the place I work so I don't need to create this example code.

June 11, 2020 Notifications System

The notifications system has now been written! This is a big milestone as it was the last "backend" service I needed to write before launch. The basic idea is that customers want to be notified to a 3rd party when their API or webhooks become slow.

As part of the launch MVP I will support Slack Incoming webhooks and email notifications, but have plans to add support for Teams, Chime, generic webhooks and potentially SMS, but this will all depend on customer feedback. I feel email and slack are fairly safe bets for the audience that I am targeting.

The notification system works like this:

  • When the "task runner" gets the list of endpoints and webhooks that it needs to run tests for, we also retrieve the notification preferences of that particular test (notifications are configured per endpoint/webhook so you can be notified for some but not others)
  • If the webhook or API endpoint responds below the configured budget for the customer, we trigger the notifications.
  • We iterate through the notification preferences and for each of them emit a message to an SNS topic based on the type of notification - the format we send to the SNS topic is standard across all notification types
  • Individual lambda's are then subscribed to those SNS topics - for now we have a slack webhook topic and lambda and email topic and lambda
  • The lambda makes the call to the API to send the notification - for slack, this is a simple POST request. For email, this is Mandrill.

Dead chuffed with the progress and can't wait to launch soon! Please feel free to reach out to me on twitter @joshghent or leave your thoughts below!

June 9, 2020 Initial Commit

Hey all! I've been sharing my progress here: https://twitter.com/joshghent/status/1241997920058163201

But here is a quick recap:

  • Came up with my idea for TurboAPI out of frustration with the current set of offerings for monitoring API and Webhook performance. Currently, no products focus on speed and do not seem to allow webhook monitoring. Products that do focus on speed, like APM's require invasive installs and complex analysis. This is a simple tool to keep on track of API performance in an automated fashion
  • I've created the skeleton of the frontend and am continuing to work on that
  • The API is complete and hosted in DigitalOcean along with the "worker" that is run on AWS

I look forward to launching soon!

I was frustrated that the current set of API monitoring tools are too basic or too expensive, I created TurboAPI. There is no other tool on the market focused solely on performance and can track webhook performance.