Skip to Content
Tares

How do I send Vercel deploys to an AI SRE?

Tares takes Vercel deploy activity three ways: a Vercel log drain, GitHub App events pushed as webhooks, or commits and pull requests polled with a personal token. The log drain is keyed by Vercel project, and the GitHub paths are keyed by repository or pull request. You can run all three side by side and let your AI SRE correlate them.

How it works

Each path answers a different part of “what changed”.

  • Vercel log drain. The vercel connector is a push source. You point a Vercel log drain (JSON) at the source’s ingest URL, and Tares stores one event per log entry. The key is project, with environment (production or preview) and source (lambda, build, edge, static, external or redirect) as labels. It also carries path, host, deployment and branch. One drain can carry several projects, and each appears as its own entity.
  • GitHub App. Events arrive as they happen by webhook: pull requests, pushes, reviews, issues, releases and CI runs (workflow_run). One source covers every repository the App is installed on. Pull requests are keyed owner/repo#number, pushes and CI runs owner/repo.
  • Personal token. Tares polls each repository every 2 minutes by default for commits and for pull requests opened, merged or closed. You add one source per repository.

The App and the token produce the same event types, so a trigger written for one keeps working when you switch to the other. Merged pull requests and Vercel log entries land in the same place, so your AI SRE can line a merge up against what a project started logging afterward. See AI SRE for how agents use those events.

Set it up

Start with the Vercel log drain, then add GitHub for the change history.

  1. Make the ingest URL public. Vercel delivers from its cloud, so a bare localhost daemon will not receive drains. Use a deployed instance or a tunnel.
  2. Create the source. In the console choose Sources, Add source, vercel. The project, environment and source labels are pre-filled and there is no required config. You can also ask a connected agent to create a vercel source and give you the ingest URL. The equivalent source looks like this:
- name: web-logs
  connector: vercel
  config:
    labels:
      - { name: project, field: project, primary: true }
      - { name: environment, field: environment }
      - { name: source, field: source }
  1. Copy the ingest URL from the source page.
  2. In Vercel, open Team Settings, Log Drains, Add Log Drain. Set the endpoint to the ingest URL and the delivery format to JSON. Vercel verifies the endpoint with an x-vercel-verify header, and Tares echoes it back from Vercel’s verification request.
  3. If Tares has auth on (tares up --auth), add a custom header to the drain. The sender uses a Bearer Authorization header holding an ingest-scoped API key. It is needed only when Tares has auth on.
  4. Add the GitHub side from GitHub. For the App, open Settings > GitHub and choose Create GitHub App, then install it on your repositories. GitHub must reach your Tares, so a local instance needs a tunnel:
cloudflared tunnel --url http://localhost:8787
TARES_PUBLIC_URL=https://<your-tunnel>.trycloudflare.com tares up
  1. Or use a token. Paste a fine-grained token under Settings > GitHub, then add one source per repository:
- name: checkout-api
  connector: github
  poll: 2m
  config:
    repo: acme/checkout-api
    credential: github
    labels:
      - { name: repo, field: repo, primary: true }
  1. Check the result on the Vercel source page. Recent events shows entries arriving, and Fields shows which projects appear and how well each field is filled. If project reads sparse, pick a denser field as the key, or slice by source or environment. More detail is on the Vercel logs page.

What you get

  • Vercel logs keyed to the service. Every entry carries its project, environment, source, deployment and branch, so you can slice a build or edge problem by any of them.
  • Change history keyed to the repository. The App sends pull requests, pushes, releases and CI runs as they happen. The token gives you commits and pull request opened, merged and closed events on a 2 minute poll.
  • Triggers that fire on a change. For example, a trigger on the github source with event_type equal to pull_request and action equal to merged fires once per merged pull request.
  • Safe delivery from GitHub. Every App delivery is checked against the App’s webhook secret, and a delivery GitHub sends twice is stored once.
  • One place for an agent to look. Deploy logs and code changes sit next to your other sources, so the agent can read them together.

When something else fits

  • Pick the GitHub App over the token if you want events as they happen, many repositories in one source, and CI run events. The token suits a single repository or a setup where you cannot install an App.
  • The log drain gives you log entries, not a list of deploys. If you only need what shipped, the GitHub App or token path alone may be enough.
  • If Tares cannot be reached from the internet and you cannot run a tunnel, neither the drain nor App webhooks will arrive. The polled token path still works.

Still stuck? Get help

Last updated on
Quickstart