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”.

Note: This is part of an open source utility called the Dev Stack Analytics Template. Analyze data from their entire stack - including tools like Vercel, Auth0, GitHub, Resend, Clerk, Stripe, and more - in one place.

Show me the 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.

I built these charts using Vercel webhooks, Tinybird, and a simple Next.js app.

To build this dashboard we have a stack like this:

1. Vercel pushes data to the Tinybird Events API via webhooks.
2. We create some SQL transformations (Pipes) in Tinybird and publish them as API endpoints.
3. 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:

1. Write a new SQL query
2. 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:

{
    "createdAt": "1734960637036",
    ...
    "payload": {
        ...
        "deployment": {
            "meta": {
                "gitlabCommitAuthorLogin": "xavijam",
                "gitlabCommitAuthorName": "Javier Álvarez Medina",
                "gitlabCommitMessage": "Adding title and description\n",
                ...
            },
            "name": "tinybird-docs",
            "url": "tinybird...vercel.app"
        },
        ...
    "type": "deployment.created"
}

I’m interested in several things in this data:

1. The user’s git login and name
2. The event type
3. The event time

I want to count how many deployments each person is creating, so I can rank them. The query looks like this:

%
SELECT 
  coalesce(
    event.payload.deployment.meta.githubCommitAuthorName::String,
    event.payload.deployment.meta.gitlabCommitAuthorName::String
  ) AS author,
  count() as commits
FROM vercel
WHERE event_type = 'deployment.created'
  AND event_time >= {{DateTime(date_from, '2024-01-01 00:00:00')}}
  AND event_time <= {{DateTime(date_to, '2024-12-31 23:59:59')}}
  AND author != ''
GROUP BY author
ORDER BY commits DESC

Pushing that query to Tinybird, I get an API that returns a result like this:

{
  ...
  "data":
  [
    {
      "author": "alrocar",
      "commits": 83
    },
    {
      "author": "sdairs",
      "commits": 18
    },
    {
      "author": "Fabrizio Ferri-Benedetti",
      "commits": 8
    },
    {
      "author": "Alasdair Brown",
      "commits": 4
    },
    {
      "author": "dependabot[bot]",
      "commits": 1
    }
  ],
  ...
}

Just a quick fetch() to pull the data:

let url = new URL(`https://api.tinybird.co/v0/pipes/git_analytics.json`)
url.searchParams.append('date_from', '2024-01-01 00:00:00')
url.searchParams.append('date_to', '2024-12-31 23:59:59')
const result = await fetch(url, {
  headers: {
    Authorization: 'Bearer ...'
  }
}) 
  .then(r => r.json())
  .then(r => r)
  .catch(e => e.toString())
...
return result.data

And via the magic of shadcn/charts, I can plot this data with little more than copy and paste:

I used shadcn chart components to visualize the response from my Tinybird endpoint

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.