Vercel is the web platform for software teams that ship fast. But how fast? And do we maintain that velocity over time?
Vercel webhooks allow you to push your data out of Vercel and do whatever you want with it. This works out of the box with Tinybird’s Events API, meaning you can push all that Vercel data straight into the world’s fastest database in a few lines of code.
If you want to start from scratch and build your own insights based on your own Vercel webhook events, you can find here a step-by-step guide to send Vercel webhooks to Tinybird.
But, in the words of daytime TV, “Here’s one I made earlier”.
Show me the money data
This dashboard (source here) can immediately show us what's happening across our Vercel team. We can see how fast we’re making changes by the number of deployments over time, and how fast we can test and iterate by plotting our deployment durations.
To build this dashboard we have a stack like this:
- Vercel pushes data to the Tinybird Events API via webhooks.
- We create some SQL transformations (Pipes) in Tinybird and publish them as API endpoints.
- A Next.js app with shadcn/charts calls the Tinybird APIs and plots the data.
As far as web app stacks go, it couldn't be much simpler.
Adding a new chart
To add a new chart, we only need to do two things:
- Write a new SQL query
- Build the chart component
Here’s what that looks like if I want to know who gets bragging rights as the fastest developer in the west.
Vercel’s webhook data looks something like this:
I’m interested in several things in this data:
- The user’s git login and name
- The event type
- The event time
I want to count how many deployments each person is creating, so I can rank them. The query looks like this:
Pushing that query to Tinybird, I get an API that returns a result like this:
Just a quick fetch() to pull the data:
And via the magic of shadcn/charts, I can plot this data with little more than copy and paste
But what else?
Vercel exposes many event types that we could use to further analyze this data, so what else could we do?
The only thing better than going fast is going faster, right?
We could plot deployment.error events over time to correlate the impact of errors against deployments and see how increasing error rates impact our shipping speed.
Or we could enrich deployment errors with deployment logs, find the most common errors, and eliminate them to improve deployment consistency overall.
Once the data lands in Tinybird, exploring and productizing these ideas takes just minutes.
Give it a go. If you need help, pop into our Slack Community and ask away.
