How to check if your tickets, issues and commits link up

What counts as a link between a ticket, an issue and a commit?#

A link between a ticket, an issue and a commit is any reference a script can follow from one record to the next without a person guessing. In most software companies that means a Jira issue key in a commit message, branch name or pull request title, a development link created by the Jira integration with GitHub or GitLab, or a Zendesk or Intercom ticket that records the Jira issue it was escalated to.

Links that live only in someone's memory, or as a pasted URL deep in a Slack thread, do not count for this check. They may be recoverable later, but anyone evaluating an engineering history wants chains it can rebuild from the records themselves: the customer report, the issue, the discussion, the code change, the review and the release that shipped it.

• 1Support to engineering: a linked issue field, an integration panel entry or an issue key in an internal note.
• 2Issue to code: development panel entries, smart commits, or the key in a branch name or pull request title.
• 3Code to release: tags, release notes or deployment records that name the pull requests they include.
• 4Discussion: review comments and issue comments that stay attached to the records above.

The three queries that measure your link rate#

The three queries that measure link rate run on exports of keys and dates, not on ticket text or source code. Pull resolved Jira issues with their keys, projects, types and resolution dates; merged pull requests or main-branch commits with their messages, branch names and merge dates; and escalated support tickets with any linked issue field.

Match issue keys across the code export with a simple pattern: an uppercase project prefix, a hyphen and a number, such as PAY-1423. The same pattern also catches strings such as UTF-8 or SHA-256, so count a match only when the key exists in the issue export. Count matches in both directions, then group every result by year and by team or Jira project. Keep the raw match file, because the same join becomes the backbone of any later package.

The method does not depend on Jira and GitHub. Linear, GitLab and most other trackers use short issue identifiers that appear in branch names, merge requests and commit messages, so the same exports and joins apply with a different key pattern.

• 1Query 1, issue coverage: of resolved bugs and stories, how many have at least one merged pull request or commit that cites their key?
• 2Query 2, code coverage: of merged pull requests, how many cite at least one issue key that actually exists in the issue export?
• 3Query 3, escalation coverage: of support tickets marked as escalated or sent to engineering, how many name a Jira issue that later resolved?

How to score the results as low, medium or high linkage#

Linkage scores work best as bands rather than a single figure, because the real question is whether complete chains can be assembled in volume. Score the three queries per year and take the weakest as that year's band; the release trace and consistency rows explain the band rather than change it.

A high band in one dimension does not make up for a low band in another. A company with strong issue-to-code links but no escalation links still has a solid engineering history; it simply does not yet have a support-to-fix history.

Where do links usually break?#

Links usually break at moments of change: a tool migration, a project key rename, a repository split or a new merge policy. The breaks are predictable, so check each one on purpose instead of assuming a low rate means engineers never linked their work.

Each break leaves a signature in the per-year results, such as a sudden drop at a migration date or a jump when a pull request template began requiring an issue key. Write the date and cause next to the score, because a reviewer will ask why a gap exists before asking how large it is.

• 1Squash merges that replaced detailed commit messages with a pull request title missing the key.
• 2Jira project moves or key renames, where old keys redirect in the browser but not in exported text.
• 3Repository migrations from Bitbucket, SVN or self-hosted GitLab that kept commits but dropped pull request history.
• 4Hotfixes pushed straight to a release branch outside the normal review path.
• 5Helpdesk switches that kept old tickets but lost their linked issue fields.
• 6Integrations connected partway through, so only later work shows development links.

Can missing links be recovered after the fact?#

Missing links can sometimes be recovered after the fact, but recovered links must be labeled for what they are. Some methods find real references the first pass skipped; others infer a likely match from timing, authorship or shared text.

Keep recorded and inferred links in separate fields, with the method noted for each. A reviewer can decide how much weight to give inferred chains, but no one can undo a dataset that blended them without saying so. A practical limit is to attempt recovery only for the years just before a known break, where the evidence is strongest and a hand-checked sample is quick to review.

Illustrative: a property management software company checks its chains#

Illustrative: a fictional property management software company runs Zendesk for support, Jira for engineering and GitHub for code. Its CTO exports keys, dates and link fields from all three and runs the three queries by year and by Jira project.

Issue and code coverage come back high for recent years and fall away before the move from Bitbucket, when pull request history was not carried over. Escalation coverage is medium: agents linked tickets for bugs but handled feature requests by email. The payments team, which always required issue keys in pull request titles, scores high throughout.

The company scopes a first package to the years after the migration, adds the payments team's earlier history, and labels a small set of recovered links as inferred. Feature request escalations stay out for now. During the fit check, the CTO shares only the band scores, date ranges and the cause of each break.

How SourceX uses linkage in a fit check#

SourceX looks at linkage early because it bears on two drivers in the SourceX Enterprise Data Value Framework: AI utility, since connected records show how work moved from request to decision to outcome, and preparation cost, since complete chains need less reconstruction. In the Supply step of the SourceX five-step transaction, SourceX asks for results like the ones described here, meaning systems, years, link bands and known breaks, rather than files.

If a package proceeds, the method behind every link, recorded or inferred, is written into the provenance section of the SourceX Evidence Packet. The supplier and the buyer then work from the same description of how each chain was built.