What are the limits of the GitHub Issues ticket connector?

Tares links one GitHub repo and one issue label to each project, reads github.com only, and has no GitHub Projects board support. GitHub Enterprise Server is not supported. You group tickets with GitHub milestones instead, and Tares reads up to 1000 issues with the label and 100 milestones in the repo.

How it works

The github_issues connector is a poll source. A project keeps its tickets in a GitHub repo: one repo and one issue label pick the issues, and those issues become the project’s tickets. Tares reads the repo about once a minute, and Sync now on the Tickets page reads at once. Every change made in GitHub becomes an event on the github_issues source, keyed by the ticket name, such as GH-12. The AI SRE guide shows how triggers and agents react to events like these.

The limits that shape how you use it:

• One repo and one issue label per project. A repo and issue label belong to one project, so you cannot share the same pair between two projects. If you leave the label out, it defaults to tares: followed by the project name.
• github.com only. GitHub Enterprise Server is not supported.
• No GitHub Projects boards. Tares does not read them. Group tickets with GitHub milestones instead. Tares shows the milestones that the labeled issues belong to, with name and order taken from GitHub.
• Up to 1000 issues with the label, and 100 milestones in the repo.
• Read-only tickets. Tares only reads from GitHub. To change a title, status, milestone or dependency, change the issue in GitHub. You cannot add a milestone in Tares, add it in GitHub.
• Projects that cannot be linked. A project that already has tickets of its own, or that keeps them in Linear, cannot be linked.

Status follows the issue. An open issue is todo, an open issue with the in progress label is in_progress, an issue closed as completed is done, and an issue closed as not planned or as a duplicate is canceled. An issue that loses the label, is deleted or moves to another repo becomes canceled in Tares rather than disappearing, so its working doc stays reachable.

Set it up

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, and 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. Create the milestones you want in GitHub, since milestones are your grouping tool. Put the issue label on every issue that should become a ticket.
3. Link the project. 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.
4. Or ask a connected agent to call the MCP tool link_github_issues:

link_github_issues(repo="acme/shop", issue_label="tares:shop")

5. Verify the link. The Tickets page shows “Tickets live in GitHub” with the repo, the issue label and the time of the last sync. Close an issue in GitHub, and within a minute the ticket moves to done and the source’s Recent events shows the change.

If you outgrow the limits, Stop using GitHub on the Tickets page returns the tickets and milestones to Tares with their working docs. You can then add and change them there again. The issues in GitHub stay as they are. Full details are on the GitHub Issues connector page.

What you get

• A clear picture of what fits before you link: one repo, one label, github.com, milestones for grouping, up to 1000 labeled issues and 100 milestones.
• Tickets that follow your issues, with status, milestones and dependencies read from GitHub. An issue that is blocked by another makes its ticket depend on that one.
• One event per change, with event_type set to ticket_created, ticket_renamed, ticket_status or ticket_removed, so triggers and agents can react.
• The provided labels ticket, project and repo on every event.
• Safe failure. If a sync fails, the Tickets page shows why, the tickets stay as they were and nothing is canceled. If 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 cancels nothing. If GitHub rate limits the sync, Tares waits five minutes before it tries again.

When something else fits

• If your issues live on GitHub Enterprise Server, or you plan work on a GitHub Projects board, this connector does not fit. Keep the tickets in Tares, or in Linear with the Linear connector.
• If a project needs more than 1000 labeled issues or more than 100 milestones, or needs several repos or labels, keep those tickets in Tares, and use Stop using GitHub to bring them back.

Related