Integration

GitHub: What shipped, so everything else can be dated to it.

Vesqo reads one repository for its releases: published GitHub releases, successful deployments, or pull requests merged into the default branch, whichever is how you ship. A release is the clock every other source is read against.

What the integration does

Most of what Vesqo writes starts with a question: what changed, and when? GitHub answers the second half. Each release, deployment or merge becomes a release event in Vesqo, and from then on Sentry's errors, PostHog's key event, the support inbox and Stripe's payments are read in the hours after it and set against the week before. A fresh release gets its own checks on top of the half-hourly run, so a bad one shows within minutes.

Pick what counts as a release: published releases if you cut them; deployments if Vercel, Heroku or a job in Actions records them on GitHub; merged pull requests if you deploy on merge and mark it nowhere. Deploying with Kamal or a script? Send the release from there instead, one call to the API with a key from Settings. GitLab is read the same way.

What Vesqo reads from GitHub

  • Published releases: tag, name, when.
  • Or successful deployments to production, or pull requests merged into the default branch: the last thirty days on the first sync, then each as it happens.
  • A webhook on the repository, so a release is known the minute it is published.
  • No code, no issues, no commits, no other repositories, and no writes. (GitHub Issues as an action, which opens an issue from a signal, is a separate connection and says so.)

How it connects

Authorize the Vesqo GitHub App and pick the repository from those the app is installed on. A GitHub App asks for its own permissions, read-only, on the repositories an owner chose: nothing like an OAuth App's repo scope, which reads and writes everything the person can. The syncs then run as the installation, with a token minted for an hour at a time, so they outlive the person who connected. Or paste a fine-grained token with read access to Contents, Deployments or Pull requests of that one repository.

Why connect GitHub

Without a release to date it to, an error spike is a mystery: it started sometime this afternoon. With one, it is a suspect: errors ×10.5 in the hours after v2.14.0, against the same hours last week. That is the difference between a chart and a signal, and between an hour of tabs and a rollback.

GitHub is the one source that changes nothing about the money and everything about the story. It is also the cheapest to connect: one repository, read-only, done in a minute.

Questions Vesqo can answer with it

  • What shipped this week, and did anything move after each release?
  • Did errors or checkouts change after v2.14.0?
  • Which release is the last one before Cortex's usage dropped?
  • How long after the release did the first support conversation open?

Signals it writes

  • Release regression: errors up after a release, against the week before.
  • Conversion drop: the key event down after a release, each hour against the same hour of the day.
  • Release impact: for a release that hurt, one card with the errors, the key event, the inbox and the money.
  • Every signal that can be dated to a release says which.

Example

See what it finds in a workspace with a bad afternoon in it.

The demo is Farol Jobs, a made-up job board with a bad release in it, every screen open. Ask it anything. Then connect your own.

Vesqo would like to count visits with Google Analytics. Google's cookies are set only if you say yes, and the site is the same either way. Cookie notice