Jira Integration Troubleshooting

This page documents the known problems with the Jira integration and the steps to resolve them. Each section describes a symptom, its cause, and the resolution.

Freshness

Changes Made in Jira Take a Long Time to Appear

An issue is closed or commented on in Jira, and Qualytics still shows the old status for up to an hour.

Cause: Without a webhook, Qualytics reads issues back on two triggers only. Opening the anomaly queues a refresh of its own linked issues, skipping any that were read in the last minute, and a background sweep re-reads every linked issue on a schedule, hourly by default and only for issues that have been idle for most of that interval.

Resolution: Register the integration's webhook in Jira so changes arrive within seconds. See Register the Jira Webhook. A self-hosted deployment that cannot receive inbound calls from Jira can shorten the sweep interval instead.

The Webhook Is Registered but Nothing Arrives Faster

The webhook exists in Jira, yet linked issues still refresh only when the anomaly is opened or the sweep runs.

Cause: The webhook may not subscribe to the events Qualytics needs, its JQL filter may exclude the projects whose issues are linked, the issues that changed may not be linked to any anomaly, or Jira may not be able to reach the deployment.

Resolution: Confirm the webhook subscribes to Issue → updated and Comment → created, updated and deleted, and that any JQL filter still covers the linked projects. Events for issues that are not linked to an anomaly are accepted and ignored by design, so test with an issue that is actually linked. For a deployment behind a firewall, check that Jira can reach the URL at all.

The Card Shows a Status the Issue No Longer Has

The ticket card keeps reporting an old status and title, and Synced X ago stops advancing.

Cause: The issue was deleted in Jira, or it can no longer be read with the integration's credentials. A read that fails leaves the stored values in place and the sync moves on to the next issue.

Resolution: Open the issue with the View button to see whether it still exists and whether the integration's account can browse it. Unlink the ticket when the issue is gone for good. See Unlink a Jira Ticket.

Status Sync

The Issue Does Not Move When the Anomaly Changes

The anomaly is acknowledged or archived, the issue receives the status note, but its own status stays where it was.

Cause: Anomaly status sync may be off, which is the default and posts the note without moving anything. The integration or that one issue may be set to read only, the mapping may leave that anomaly status unchanged, or the Jira account may not be allowed to transition issues in that project.

Resolution: Turn on Anomaly status sync and map the anomaly status to a status in your workflow. Check the issue's Two-way / Read only button, and make sure the integration's Jira account has permission to transition issues in the target project. When the project's workflow has no status by the mapped name, the issue moves to a status in the same category instead.

The Anomaly Does Not Move When the Issue Closes

An issue reaches Done, but the anomaly stays Active or Acknowledged.

Cause: Every issue linked to the anomaly has a say, read only ones included, and the anomaly moves only when all of them sit at statuses mapped to the same anomaly status. One issue still open, or one at a status that is not in the mapping, holds the anomaly where it is. An archived anomaly is never moved by an issue either.

Resolution: Check the other issues on the anomaly's Tickets panel and close or unlink the ones that no longer represent the work. Add the missing status to the mapping when your workflow uses a name it does not name yet. See Anomaly status sync.

Comments

A Comment Written in Jira Is Not on the Timeline

Someone comments on the issue and the anomaly's Timeline seems unchanged.

Cause: Usually one of three things. The comment is on the Timeline but carries the time it was written in Jira, so it sits at that point in the thread rather than at the top. The read-back may not have run yet, which is the same freshness question as above. Or the comment is one Qualytics itself wrote on the issue, and those are never read back.

Resolution: Look for the comment at its own time on the Timeline, where it is shown with the ticket it came from beside the timestamp. If it is genuinely missing, register the webhook or wait for the next read.

A Mirrored Comment Has No Author

A comment from Jira is on the Timeline under a plain name rather than a Qualytics user.

Cause: Comments are attributed by matching the author's email address to an active Qualytics user. Jira Cloud hides author emails by default, so for most people no email reaches Qualytics and the comment is stored under the author's Jira display name instead.

Resolution: None is needed, because the comment is complete and readable either way. Such a comment cannot be edited in Qualytics, because it has no author there, though an Admin can delete it.

A Comment Written in Qualytics Never Reached the Issue

The comment is on the Timeline but no copy appears in Jira.

Cause: The integration is set to read only, or that one issue is. Both switches stop every write to the issue, comments and status notes alike.

Resolution: Set the issue back to Two-way on its card, or turn the integration's Two-way sync back on. Comments written while an issue was read only are not sent retroactively.

An Edit or Deletion Did Not Carry Across

A comment is edited or deleted in Qualytics and the copy on the issue still reads as before.

Cause: The copy follows the same switches as the original push, so an issue that has since been set to read only keeps the copy as it was.

Resolution: Restore two-way sync for that issue and edit the comment again. Deleting the copy in Jira is not the same thing in reverse. It never deletes the comment in Qualytics, it only stops the two from syncing.

Setup

Connecting Jira Is Refused

The Add Jira Integration modal does not accept the values and no integration is created.

Cause: The credentials are validated against the instance before anything is stored, so whatever Jira rejects stops the save. The usual reasons are a malformed instance URL, credentials that are not in the email:api_token form, a token that has been revoked or regenerated, and an account that cannot browse the projects being selected.

Resolution: Check that the URL is complete, starts with https:// and carries no trailing slash. Check that the credentials hold a colon and no spaces, and that the token is still valid and belongs to that same account. Then confirm in Jira that the account can browse every project you are selecting. See Add Jira Connection for what each field expects.

Requests to Jira Stopped Working

The integration connected fine before and now every read or write fails.

Cause: The API token was revoked or regenerated in Atlassian, or the account behind it lost access to the projects. The stored credentials are tested only when they are saved, so nothing tells Qualytics that a working token has since been withdrawn.

Resolution: Create a new token, following Jira Configuration, then replace the credentials on the integration. See Edit Jira Connection.

The Webhook URL Box Is Not in the Modal

The integration is open but there is no Webhook URL to copy.

Cause: The URL is minted for an integration that already exists, so it is only in the edit modal, never in the add form. Reading it also requires the Manager or Admin role.

Resolution: Save the integration first, then reopen it with Edit. See Edit Jira Connection.

Connecting Jira Fails While ServiceNow Is Connected

The integration cannot be created and the platform refuses the connection.

Cause: Only one ticketing integration can be active at a time.

Resolution: Disconnect the existing ticketing integration first. See Unlink Jira Connection for the equivalent steps.

Limitations