Skip to Content
Tares

What happens to my tickets when the GitHub Issues sync fails or GitHub rate limits it?

Tares keeps your tickets exactly as they were when a GitHub Issues sync fails, and it cancels nothing. The Tickets page shows why the sync failed, and the next sync picks up once you fix the cause. When GitHub rate limits the sync, Tares waits five minutes before it tries again.

How it works

Tares reads your linked repo about once a minute and turns every issue with your issue label into a ticket named GH-12, GH-13 and so on. A failed read never changes those tickets. Three cases matter.

  • A sync fails. Causes include a revoked credential, a repo the credential can no longer see, or GitHub being unreachable. The Tickets page shows the reason. The tickets stay as they were and nothing is canceled. When you fix the cause, the next sync picks up.
  • No issue carries the label any more while tickets are still open. Tares stops with an error that asks whether the label was renamed, and it cancels nothing. Put the label back, or stop using GitHub Issues for the project.
  • GitHub rate limits the sync. Tares waits five minutes before it tries again. If you click Sync now during that wait, the Tickets page counts down. The API answers 429 with a Retry-After header, so a script that calls it knows how long to wait.

This differs from the normal case, where one issue loses its label, is deleted or moves to another repo while the sync itself works. That ticket becomes canceled in Tares instead of disappearing, so its working doc stays reachable. A failed sync, or a label that matches no issue at all, never triggers that cancellation.

Tares only reads from GitHub. Your sessions create and change issues in GitHub with gh, so a failed sync never stops them from working in GitHub.

Set it up

Set up the link once, then you know where to look when a sync fails. The full connector reference is on the GitHub Issues connector page, and the wider picture of how Tares fits into operations is in AI SRE.

  1. Add a GitHub credential in Settings > GitHub. It must be able to read the repo’s issues. A fine-grained token needs the repo with Issues: read. A classic token needs the repo scope. A GitHub App needs the Issues permission and must be installed on the repo, because an App with no installation is skipped. Tares tries the stored credentials one after another until one can read the repo.
  2. On the project’s Tickets page, click Use GitHub Issues, pick or type the repo as owner/name, check the issue label and click Link. Or ask a connected agent to call the MCP tool:
link_github_issues(repo="acme/shop", issue_label="tares:shop")
  1. Leave the issue label out and it defaults to tares: followed by your project name.
  2. Check the Tickets page. It shows “Tickets live in GitHub” with the repo, the issue label and when the last sync ran. That timestamp is your first signal that syncing has stopped.
  3. When a sync fails, read the reason on the Tickets page and fix it. Restore a revoked credential, give the credential access to the repo again, or put back a label that was renamed.
  4. Click Sync now to read at once. If GitHub rate limited the sync, the page counts down the five minute wait, and you can simply let it finish.

What you get

  • Tickets that stay in place through any failed sync. Titles, statuses, milestones and dependencies remain as the last good sync left them.
  • A reason on the Tickets page, so you do not have to guess whether the cause is a credential, a repo or GitHub itself.
  • No surprise cancellations. A missing label stops the sync with an error instead of canceling your open tickets.
  • A rate limit that clears on its own. Tares retries after five minutes, Sync now shows the countdown, and API callers get a 429 with a Retry-After header.
  • Recovery without cleanup. You fix the cause, and the next sync picks up where the last good one left off.
  • Events that keep flowing once syncing resumes. Each change in GitHub becomes an event on the github_issues source, so triggers and agents react as before.

When something else fits

If you want to leave GitHub as the ticket home for good, click Stop using GitHub on the Tickets page. The tickets and milestones return to Tares with their working docs, and you can edit them there again while the issues in GitHub stay as they are. GitHub Enterprise Server is not supported, and a project is limited to one repo and one issue label, so a setup beyond that needs tickets kept in Tares or in Linear.

Still stuck? Get help

Last updated on
Quickstart