Change Suspects

What changed just before this broke? Change Suspects ranks the changes made before a Jira incident started, shows the evidence for each and links the one your team marks as the cause.

Comment

Try it

Inspiration

Many incidents start with a change: a deploy, a configuration tweak, a library upgrade. The first question in an incident is "what changed?", and the answer is spread across projects, deploy logs and people's memory. Many of those changes are already in Jira as work items with resolution times, labels and components. What is missing is a view that lines them up against the moment the incident started and says which ones deserve a look first.

What it does

  • Change suspects panel on the incident: the changes resolved or deployed in the 24 hours, 3 days or 7 days before the start, across every project the person can see, in ranked order. Each suspect shows why it is there: how long before the start it went in, the component or label it shares with the incident, the words the two share and the change risk when one is recorded. Weak matches stay folded away; changes made after the start, such as a rollback, are listed on their own.
  • Start time: an incident starts when it was created unless the team sets the real start in the panel, in their Jira time zone.
  • Mark as cause links the change to the incident with Jira Service Management's "causes / is caused by" link type when the site has it, otherwise "relates to", and records the mark on the incident.
  • Timeline comment: one click posts the changes worth a look, the start, later changes and the report time as a comment with links, ready for the incident review.
  • Project page: incidents from the last 30 days, the change most likely involved in each and whether a cause has been marked.
  • Rovo agent "Change Suspects" with three actions, list-suspect-changes, mark-suspect-change and list-recent-incidents, which the app also exposes as tools on the Atlassian MCP server. An open-source SKILL.md in the repository tells third-party agents how to use them.
  • Load sample incidents creates a fictional web shop with two incidents and the changes around them, timed relative to now, so a judge sees a ranked list within a minute.

The ranking shows where to look first. It does not prove a cause, so a change is only called the suspected cause after a person marks it.

How we built it

Forge with UI Kit: a jira:issuePanel, a jira:projectPage, a jira:entityProperty that indexes deploy and start times for JQL, resolvers for the UI, and action, rovo:agent and rovo:mcp modules for Rovo. One JQL search finds the work items resolved, or recorded as deployed, around the start. The ranking is plain JavaScript with no network access: recency (1 just before the start, 0.5 at six hours, 0.2 at a day) times relevance (a shared component or label, word overlap weighted so that rarer words count for more, and change risk). It shows each result as Strong suspect, Possible or Weak with the reasons in words. Deploy times come from an issue property, change-suspects, that a pipeline or an Automation rule can set; without it a change counts from its resolution time. mark-suspect-change is an UPDATE action, so Rovo asks the user to confirm before the app changes Jira. All calls run as the current user (asUser), the app keeps no data outside the Jira site and it calls no language model. Unit tests cover the time arithmetic and time zones, the word statistics, the ranking on the sample, the timeline and the sample loader.

Challenges we ran into

  • JQL reads dates in the searching user's time zone, so the app searches with a day of margin and applies the exact window in code.
  • The same word is often written two ways in incidents and changes ("time out" and "timeout", "roll back" and "rollback"), so the app joins those forms before comparing.
  • A start time typed in the panel has to mean the wall-clock time Jira shows, so the panel converts it with the time zone in the user's Jira profile rather than the browser's. UI Kit's time picker lists office hours by default, and incidents also start at night, so the editor lists the whole day and accepts typed times.
  • Jira's entity property index silently skipped times written with milliseconds, so JQL found no deploy times until the app stored them in whole seconds.
  • Browse links built from the API's self URLs pointed at api.atlassian.com; the app now takes the site address from serverInfo.
  • With the sample loaded in two projects, one project's sample changes showed up as suspects in the other. Sample changes now count only in the project they were loaded into.

Accomplishments that we're proud of

  • Every rank comes with its reasons, so a responder can check or overrule it at a glance.
  • The rollback made after the start appears next to the suspects, which can confirm the strongest one.
  • The timeline comment turns the investigation into the first draft of the review notes.

What we learned

  • A ranking that states its reasons is easier to check and overrule than a score on its own.
  • An issue property is a light way to bring deploy times into Jira without another integration.

What's next for Change Suspects

  • Read deployments and pull requests from the Teamwork Graph and from Jira's deployment information, so changes made outside Jira work items count too.
  • Learn weights per team from incidents whose cause was marked.
  • Comment on a new incident with its top suspects automatically.

Built With

Share this project:

Updates

Submission history