Work tracking: tickets in Jira
Raise a Jira issue from an incident, failed request, drift finding, attention signal or security finding in one click, as yourself, with its context.
Work tracking turns something that broke into a ticket your team can pick up, without copying anything by hand. One click on an incident, a failed request, a drift finding, an attention signal or a security finding creates a Jira issue with:
- what happened: the endpoint, status codes, timings, when it started and how often;
- where: the environment and bucket;
- what came before it, when ApiTraffic knows: the deploy, and the alerts in the incident;
- a link back to the failure in ApiTraffic;
- a public, read-only link to the sample requests behind it, for people without an ApiTraffic seat.
Each issue is created with your own Jira account, so you are its reporter and your Jira permissions apply. The issue and the failure stay linked: the failure shows the issue’s key and status, and a second click opens the issue instead of creating another one.
Jira Cloud and Jira Data Center are supported. Trackers are pluggable, so more (such as Linear and GitHub Issues) can be added without changing how this works.
Before you begin
- Plan. Your plan must include Work tracking. Share links in tickets also need Share links.
- A Jira destination. An owner or admin connects a Jira project once (see Set up a destination). The same destination can also receive alert tickets.
- Your Jira account. Each person connects their own Jira account the first time they raise a ticket. ApiTraffic asks for it when you click, then carries on with the same click.
- Role. Any member can raise and unlink tickets and connect their own Jira account. Setting up destinations is for owners and admins.
Set up a destination
Add a Jira channel
On Settings → Integrations → Work tracking, click Add a Jira destination (or, later, add a Jira channel in Settings → Alerting → Channels). Enter the site and the destination’s own credential, then choose the project, issue type and resolve status from the lists Jira gives, as described in Channels. ApiTraffic uses this credential to read issue status and to post notes such as “possible duplicate”; tickets people raise use their own accounts.
Choose the one-click settings
Go to Settings → Integrations → Work tracking. For each destination you can set:
- Use for one-click tickets, on by default.
- One-click default for every bucket, or some buckets. With one destination, it is the default automatically.
- Issue type per kind of failure, for example Bug for incidents and Story for drift findings, chosen from the project’s issue types once you have connected your own Jira account on the page. The destination’s own issue type is the default.
- Share link in tickets: whether to add a public link to the sample requests, when it expires (7, 30 or 90 days, or never; 30 days by default), and what it shows (below).
Raise a ticket
The Create Jira issue button is on:
| Where | What it raises |
|---|---|
| An incident (All buckets → Incidents) | The incident, with its alerts and the deploy before it |
| A failed request’s ⋯ menu (status 400 or above) | That request |
| A drift finding’s detail | The finding and the schema paths that changed |
| The dashboard’s attention panel, in a signal’s or incident’s ⋯ menu | The signal or incident |
Click Create Jira issue. The issue is created in the one-click destination for the bucket, and the button turns into its key with a status badge, for example OPS-1234 In Progress. Click it to open the issue in Jira.
To change anything first, use the arrow next to the button and choose Review before creating. You can pick the destination, project, issue type and priority, change the title, add labels, assign the issue to yourself, leave out the share link, and fill in any field your Jira project requires. The fields come from your Jira project, so a required field can’t be missed. The dialog starts on the destination and project you used last in this bucket, or on the bucket’s default from the work tracking settings if you haven’t raised a ticket here yet. The issue type starts on the one the settings give this kind of item. Type a label and press Enter or a comma to add it; select the x on a label to remove it. Assign to me is off unless you turn it on.
The first time
The first time you raise a ticket for a destination, the button reads Connect Jira to create:
- Jira Cloud: a window opens where you sign in to Atlassian and allow access. The account you use must be able to reach the destination’s Jira site. When the window closes, the ticket is created.
- Jira Data Center: paste a personal access token from your Jira profile (Profile → Personal Access Tokens). ApiTraffic checks it with Jira before saving it.
Your connection is stored encrypted and is only used for tickets you raise. Disconnect it any time in Settings → Integrations → Work tracking.
When the same problem comes back
If the failure is the same problem as an open ticket on the destination (the same alert, the same error on the same endpoint, the same drift, the same signal) raised in the last 30 days, the button offers that ticket first: Add to OPS-1234 · In Progress. One click adds the new failure to the ticket as a comment, with its own facts and share link, and links the failure to the ticket. To open a separate ticket instead, use the arrow and choose Create a new ticket.
A ticket that is already done is never offered. A new ticket for the same problem says “Related: OPS-1234 (done)” and is linked to the old one in Jira.
What goes in the ticket
| Part | Content |
|---|---|
| Title | For example [critical] INC-142 Error rate on POST /v1/orders or 500 on POST /v1/orders |
| Summary | One line on what happened |
| Facts | Endpoint, status, severity, timings, first and last seen, counts, environment, bucket, who raised it and where from |
| Sections | The incident’s alerts, the deploy before it, the slowest spans, the drift’s changed fields |
| Links | Open in ApiTraffic, and the public link to the sample requests with its expiry date |
| Labels | apitraffic, plus a hidden label ApiTraffic uses to avoid duplicates |
A security finding’s ticket carries the package and version, the advisory and CVE ids, the severity and whether it is exploited in the wild, where it runs, the fixed version and the upgrade step, and its WAF coverage. It has no sample requests. Set its issue type (Bug, for example) per destination, as for the other subjects; raising it acknowledges the finding.
Request and response bodies, headers, query strings, cookies and IP addresses are never written into a ticket. Text that came from your traffic, such as a path or an error message, is written as plain text, so it can’t add links or images to the issue.
The share link
The link in a ticket opens a public, read-only page with up to 10 sample requests behind the failure: the request itself, a drift finding’s evidencing requests, or recent failing requests on the endpoint. It works like any other share link, with two differences:
- What it shows is set per destination. Metadata only (the default) shows the method, path, status, timings, error message and span names and durations, with no bodies, headers, tags or span text. Full requests, as captured shows everything a normal share link shows.
- The requests are fixed. The link points at a collection made for the ticket, listed under Collections with a Ticket evidence badge. Its requests can’t be added or removed, and it doesn’t count toward your plan’s collection limit.
The link expires on the date written in the ticket. Revoking it (in Settings → Shared links, or on the collection) adds a comment to the ticket saying so. Requests in it follow your bucket’s retention, like any collection.
Status and staying connected
The button shows the issue’s status, read from Jira with the destination’s credential about every 5 minutes while you look at it, and in the background for open tickets of the last 90 days.
- If the destination can’t read an issue (it’s in a project the destination can’t see, or it was deleted), the status shows as unknown. ApiTraffic never decides an issue was deleted from a failed read. After 7 days unknown, the issue is no longer offered for recurring problems. To remove the link, choose Unlink.
- Unlink detaches the issue from the failure. The issue itself is left alone.
- A failure can have more than one ticket: choose Create another ticket from the button’s menu.
Reliability
Jira can be slow or briefly unavailable, and it doesn’t offer a way to make “create this issue” safe to repeat. ApiTraffic handles it like this:
- If Jira doesn’t answer within a few seconds, the button shows Creating ticket… and ApiTraffic keeps trying in the background for 15 minutes. You can leave the page.
- Before every retry, ApiTraffic checks whether the earlier attempt reached Jira after all, and links that issue instead of creating another.
- If Jira can’t be reached to check, the button shows Checking whether the ticket was created… for up to 24 hours. Clicking again re-checks first.
- If two issues were still created (rare: Jira took more than a minute to index the first one), the ticket shows Possible duplicate: OPS-1235 and ApiTraffic comments on the extra issue so it can be closed.
- If you remove a destination, tickets still being created on it stop.
Errors
| Message | What to do |
|---|---|
| Connect your Jira account to create tickets as yourself. | Click the button and connect, or connect in Settings → Integrations → Work tracking. |
| Your Jira connection has expired. | Reconnect it. This happens when Jira revokes access or you change your password. |
| Jira did not allow this ticket for your account. | Your Jira account can’t create issues in that project. Choose Review before creating and pick another project, or ask your Jira admin. |
| Jira needs some fields to be filled in or changed. | The review dialog opens with the fields Jira asked for. |
| That ticket is not visible to your Jira account, or was deleted. | When adding to an open ticket: create a new ticket instead. |
| Choose a ticket destination. | There is no one-click default for this bucket. Pick one in the review dialog, or ask an admin to set a default. |
For admins
- Settings → Integrations → Work tracking lists every member’s Jira connection. Revoke deletes a member’s tokens at once.
- When a member leaves the account, their Jira connections are revoked and their tokens deleted. A ticket they were still creating fails with “the person who raised this no longer has access”, and anyone can raise it again as themselves.
- Every ticket raised, added to, failed or unlinked, and every connection made or removed, is recorded in the account’s activity log.
From an AI agent
The MCP server has create_work_item and list_work_items, so an agent that has found the cause of a failure can file the ticket, with the same content and share link, as the person the MCP token belongs to. That person must have connected their Jira account. See MCP tools.
API
Everything on this page is also available through the work tracking API.