Skip to Content
Tares

Why are no GitHub webhook deliveries reaching my self-hosted Tares, and how do I fix it?

Tares receives GitHub App deliveries once GitHub can reach your Tares, the App is installed on the repository, and the webhook secret on GitHub matches the credential in Tares. A local tares up is not reachable from the internet, so run a tunnel and set TARES_PUBLIC_URL to its address. Check recent deliveries under Advanced in GitHub’s App settings, and if they show a 401, reconnect from Settings > GitHub.

How it works

With the GitHub App, GitHub pushes events to Tares as they happen: pull requests, pushes, reviews, issues, releases and CI runs. Tares stores the App (its id, private key and webhook secret) as a credential and creates a github source for its webhook. Four things have to line up for events to arrive:

  • GitHub can reach Tares. A local tares up listens on your machine only. GitHub needs a public address, so you run a tunnel and use its address as the public URL. The App can be created without one, and deliveries start once Tares is reachable.
  • The App is installed on the repository. The App only sends events for repositories it is installed on. An installation that was not started from your Tares, such as someone installing a public App on their own account, is not added.
  • The App uses the right address. GitHub sends deliveries to the address the App was created with. On the setup page, that is the address under Address and App name.
  • The signature matches. Tares checks every delivery against the App’s webhook secret before it stores anything. An unsigned or wrongly signed request gets a 401 and is counted on the credential’s row in Settings > GitHub.

A delivery GitHub sends twice is stored once, so a retry from GitHub does not create duplicates. See GitHub for the full connector page, and AI SRE for how these events feed your triggers and agents.

Set it up

Work through these in order until deliveries arrive.

  1. Make your Tares reachable. Start a tunnel, then start Tares with the tunnel’s address as the public URL:

    cloudflared tunnel --url http://localhost:8787
TARES_PUBLIC_URL=https://<your-tunnel>.trycloudflare.com tares up

  2. Check the address the App uses. Open Settings > GitHub. In the create flow, under Address and App name, confirm the address is how GitHub reaches this Tares. If you created the App before you had a tunnel, check the address it was created with against your current public URL.

  3. Confirm the App is installed on the repository. In Settings > GitHub, choose Install on GitHub, pick the repositories and install. Events only come from repositories the App is installed on.

  4. Read the recent deliveries on GitHub. Open the App’s settings on GitHub and go to Advanced. GitHub lists recent deliveries there with their responses. Use the response on each delivery to see what Tares answered.

  5. If a delivery shows a 401, reconnect. A 401 means the webhook secret on GitHub does not match the credential’s. A recreated App gets a new secret. Reconnect the App from Settings > GitHub so both sides hold the same one. You can also see the refused count on the credential’s row in the same place.

  6. Trigger a new event. Open or update a pull request in an installed repository, then look at the github source in Tares for the new event.

If you already had an App, you added it through the API with its app id, private key, webhook secret and installation ids, and you pointed the App’s webhook at the github source’s ingest URL. Check that the webhook URL on GitHub is that ingest URL, reachable through your tunnel, and that the secret you gave Tares is the one set on GitHub.

If you see a 403 from GitHub instead, the App lacks a permission. The error names the call. After you change permissions, accept the new ones on GitHub.

What you get

  • Pull requests, pushes, reviews, review comments, comments, issues, releases and CI runs from every repository the App is installed on, in one github source.
  • Events that arrive as they happen, with labels such as repo, action, number, author, branch and conclusion that your triggers can filter on.
  • Refused deliveries counted on the credential’s row in Settings > GitHub, so you can see that signatures are failing without reading logs.
  • Deliveries that are checked against the webhook secret before anything is stored, and stored once even when GitHub sends them twice.
  • Triggers that keep working if you later switch between a personal token and the App, because both produce the same events.

When something else fits

  • If you do not want to run a tunnel or expose Tares, use a personal token instead. Tares polls each repository every 2 minutes by default, and you add one source per repository. It reports commits and pull requests opened, merged or closed, but not reviews, issues, releases or CI runs.
  • If you want GitHub managed for you, Tares Cloud connects the App from your workspace settings with Connect GitHub, and there is no tunnel to run.

Still stuck? Get help

Last updated on
Quickstart