Jira Cloud integration
Connect a Jira Cloud site to AvsB. A guardrail is a metric you are not trying to improve but do not want to make worse, like page load time or refund rate. Tickets are auto-filed when an experiment declares a winner, breaches a guardrail, or another event you map fires. Tickets show smart-card previews of the AvsB results page, and the results page lists every linked ticket with its current status.
Only Jira Cloud sites on the Standard, Premium, and Enterprise editions are supported. Jira Server and Data Center are not supported. Free is blocked: Atlassian's rate limits on the Free edition are too tight for our ticket-creation cadence.
Prerequisites
- You must be a Jira site admin, or have Browse projects and Create issues on at least one project.
- You need the Manage integrations permission in AvsB.
- The AvsB Atlassian app must be installable on your tenant. No marketplace listing is required for the OAuth handshake.
Connect a site and pick a project
Adding a Jira destination is one modal with four steps. You do all of them in one sitting.
Open the Jira card
Open Organization Settings, then the Integrations tab. Find the Jira card and click Add Jira destination.
Connect a Jira Cloud site
Click Connect Jira site. AvsB redirects you to Atlassian to sign in and approve the app, then back to AvsB. Pick the site from the list (or connect another one), then select Next.
Pick a Jira project
Choose the Jira project new tickets should be created in. This is the Jira-side project. Which AvsB project's events feed this destination is a separate choice, covered below.
Map event types to issue templates
A table lists every notification event. Toggle the ones that should file a ticket, and edit the issue type, priority, summary template, and labels for each row. AvsB pre-fills sensible defaults for the events in the table below.
Name and save
Give the destination a name, for example "Jira: ROLL (rollouts)", and click Save destination.
- Click Add Jira destination on the Jira card.
On the mapping step, AvsB pre-fills the issue type, priority, and summary template for safety events and rollout decisions. Untoggle a row to skip filing tickets for that event, or edit its template.
AvsB stores the OAuth refresh token encrypted at rest, so the connection survives access-token expiry without asking you to reconnect. A background job renews the access token shortly before it runs out, once per hour, in the background.
Every row you can edit in the mapping table:
- Issue type: Task for rollouts, Bug for safety events, by default.
- Priority: Medium for rollouts, High for safety events, by default.
- Summary template: supports
{{variable}}substitution. - Description: defaults to a structured ADF doc with key stats, configuration, and a smart-card preview link. You can supply a custom plain-text or ADF JSON template instead.
- Labels: applied to every issue created from this event type.
Finishing this wizard, even sending a successful test ticket, does not turn anything on by itself. A Jira destination only fires for the AvsB projects you route to it, which is a separate step covered next.
Route events from a project
A Jira destination lives at the organization level, but routing is per project. After you finish the wizard above, open each AvsB project that should file tickets. Click Settings, then the Notifications tab. Find this Jira destination and turn on the events you want it to receive. Repeat for every project that should use it.
Skipping this step is the most common reason a newly connected Jira destination stays silent. The wizard above and the Send test ticket button below both work with no project ever routed to it, because neither one goes through the same delivery path a real event does.
Default mappings
| Event | Issue type | Priority | Default summary |
|---|---|---|---|
experiment.winner_declared | Task (labelled rollout) | Medium | [Rollout] {{winnerVariationName}} won on {{experimentName}} |
experiment.guardrail_breached | Bug (labelled incident) | High | [Guardrail] Traffic health breached on {{experimentName}} |
experiment.guardrail_metric_breached | Bug (labelled incident) | High | [Guardrail] {{guardrailMetric}} breached its safety margin on {{experimentName}} |
experiment.code_error_detected | Bug (labelled incident) | High | [Code error] Variations failing on {{experimentName}} |
experiment.srm_failed | Bug (labelled investigation) | High | [SRM] Sample-ratio mismatch on {{experimentName}} |
flag.rule_activated | Task (labelled flag-rollout) | Low | [Flag rule live] {{ruleName}} on {{flagName}} |
flag.srm_failed | Bug (labelled investigation) | High | [SRM] Sample-ratio mismatch on flag rule {{ruleName}} |
flag.guardrail_breached | Bug (labelled incident) | High | [Guardrail] Traffic health breached on flag rule {{ruleName}} |
commerce.job_failed | Bug (labelled commerce) | High | [Commerce] {{kind}} failed |
| All other events | Disabled by default: toggle on if you want them. |
commerce.job_failed is one of five background-work events (a failed catalog import, a completed import, a finished recommendation run, an activated dataset version, or a completed feed sync). It is the only one of the five enabled by default, since a failure is the one background-work moment worth a ticket by default.
Template variables
Available variables per event type. Unknown variables render as an empty string.
| Event | Variables |
|---|---|
experiment.winner_declared | experimentName, winnerVariationName, primaryMetricName, lift, confidence, sampleSize, engine, declaredAt, resultsUrl |
experiment.guardrail_breached | experimentName, experimentId, projectName, engine, detectedAt, resultsUrl |
experiment.guardrail_metric_breached | experimentName, experimentId, projectName, guardrailMetric, detectedAt, resultsUrl |
experiment.code_error_detected | experimentName, experimentId, projectName, severity, affectedVariations, detectedAt, resultsUrl |
experiment.srm_failed | experimentName, experimentId, projectName, engine, pValue, detectedAt, resultsUrl |
flag.rule_activated | flagName, ruleName, environment, activatedAt, activatedBy, resultsUrl |
flag.srm_failed | ruleName, ruleId, flagName, projectName, engine, detectedAt, resultsUrl |
flag.guardrail_breached | ruleName, ruleId, flagName, projectName, engine, detectedAt, resultsUrl |
flag.results_ready | ruleName, ruleId, flagName, projectName, engine, digestDate, resultsUrl |
commerce.job_failed | kind, projectId, projectName, reason, link |
Custom ADF descriptions
Description templates accept either plain text with mustache placeholders or a full Atlassian Document Format JSON document. ADF JSON must be a top-level doc node:
{ "version": 1, "type": "doc", "content": [ { "type": "paragraph", "content": [ { "type": "text", "text": "Winner: " }, { "type": "text", "text": "{{winnerVariationName}}", "marks": [{ "type": "strong" }] } ]}, { "type": "paragraph", "content": [{ "type": "inlineCard", "attrs": { "url": "{{resultsUrl}}" } }] } ]}Bodies exceeding Jira's 32KB description limit are truncated automatically with a clear note at the end.
De-duplication and comment-on-existing
If the same event fires twice for the same experiment (for example, a guardrail breaching again), AvsB does not file a second ticket. It adds a comment to the existing ticket instead. A ticket counts as open as long as its Jira status category is not done. Before deciding, AvsB checks the ticket's current status in Jira if what it has on file is more than an hour old, so a repeat alert never lands as a comment on a ticket your team has already finished.
How often statuses are refreshed. AvsB re-checks an open ticket about once an hour and a finished one about once a day, and it stops checking any ticket 90 days after the link was made. If a ticket is deleted in Jira, AvsB stops tracking it. The row stays on the results panel showing the last status it saw, and the next matching event files a fresh ticket.
Once a ticket moves to Done, the next matching event files a new ticket, and the results panel switches to showing that new one.
AvsB-side linked tickets panel
Every experiment results page and flag rule results page now shows a Linked Jira tickets panel. Each row displays the issue key (clickable), the current status, the event that spawned it, and the create date.
You can also link a ticket by hand. Click Link a Jira ticket, paste an issue key like ROLL-1234, and pick which Jira destination it belongs to.
Sending a test ticket
Each Jira destination card has a Send test ticket button, under Organization Settings, then Integrations. Click it to open a modal showing the site, project, and issue type this destination uses, plus a picker for which event to simulate. It defaults to experiment.guardrail_breached, since that event produces the fullest ticket.
Send test ticket calls Jira directly. It skips the normal delivery path, so it never checks whether any AvsB project is routed to this destination. A test can succeed while production stays silent, because nothing routes to it yet. Confirm routing on the project's Notifications tab, described above.
On success, the modal shows the new issue key, a link to Open in Jira ↗, and a Delete this test ticket button. Click Delete and AvsB removes the ticket from your Jira project, so testing leaves nothing behind. If you leave it, the ticket stays clearly marked: its summary is prefixed [TEST] and it carries the label avsb-test-ticket. On failure, the modal shows Jira's own error message: project not found, invalid issue type, insufficient scopes, an expired refresh token, and so on.
Sending a test ticket requires the manageIntegrations permission. Both the send and the delete are recorded in the audit log, as JIRA_TEST_TICKET_SENT and JIRA_TEST_TICKET_DELETED.
Audit log
The following audit actions are recorded for Jira:
JIRA_SITE_CONNECTED/JIRA_SITE_DISCONNECTED/JIRA_SITE_REVOKEDJIRA_ISSUE_CREATED/JIRA_ISSUE_COMMENTEDJIRA_TEST_TICKET_SENT/JIRA_TEST_TICKET_DELETEDJIRA_LINK_CREATED_MANUALLY/JIRA_LINK_REMOVEDJIRA_TEMPLATES_UPDATED
Troubleshooting
Token expired
The destination card displays a banner if Atlassian rejects the stored refresh token. Click Reconnect to run the OAuth flow again. Pending deliveries re-queue automatically once the connection is restored.
Project moved or archived
A 403 or 404 from Jira disables the destination and surfaces a repair banner. Edit the destination, pick the new project, and the route resumes.
Ticket was created but I expected a comment
AvsB treats a linked ticket as open unless its Jira status category is done. If your workflow marks that status category done for a column you do not consider finished, AvsB reads the ticket as closed. The next matching event then files a new ticket instead of commenting on the old one.
Issue type doesn't exist in our project
If a Jira admin renames or deletes an issue type, the next create call fails with 400. The destination shows a Refresh templates action that re-fetches the project's issue types and prompts you to re-map.