Getting help with Impediment Ledger
Most questions are answered by the Diagnostics tab or the guide. When they are not, write to us.
Contact
Send your question to the support address below. We answer by email.
Support email: [email protected]
Response-time target: 2 business days.
Reporting a security issue
Please report vulnerabilities privately to the security address below rather than in a public channel. We respond to security reports within 24 hours.
Security email: [email protected]
What to include
- The project key and the issue key, and whether the project is company-managed or team-managed.
- What the admin Diagnostics tab shows for the project: capability, tracking start, last check and repair backlog.
- Whether the license is active. The admin page shows a warning at the top when it is not.
- When the issue was flagged, and how: in Jira, by Automation or from the app.
Common issues
What a message or a symptom usually means, and what to do.
| Symptom | What to do |
|---|---|
| The panel says the app isn't set up yet. | No Flagged field has been confirmed. A Jira admin opens Get started, runs Check configuration and chooses Use this field. |
| “Blocker tracking is off in this project.” | Turn it on in Project settings → Impediment Ledger. |
| An issue was flagged but no blocker appears. | An event was lost or Jira's history arrived late. The repair queue fills it in within 5 minutes; to do it now, recheck the issue on the Diagnostics tab. |
| The issue's flag can't be read right now. | The app cannot reach the issue: an app access rule or data security policy, or the issue was deleted or moved. Check the app's access rules. The ledger marks the issue and deletes nothing; an open blocker the app cannot read for longer than the retention period is deleted. |
| Diagnostics shows INVALID_CONFIG or AMBIGUOUS. | The Flagged field has several contexts, a project-limited context, is hidden, has its Impediment option disabled, or there are several candidates. Run Check configuration and fix what it reports in Jira's field configuration. |
| Diagnostics shows UNAVAILABLE. | A Jira Service Management project, or a site without a Flagged field. These are not supported. |
| A report shows fewer blockers than expected. | You only see issues you can browse, by design. Above 2,000 blockers a report is partial: choose a shorter period or fewer projects. |
| A project switched to READ_ONLY (flag writing). | Jira answered a flag write unexpectedly. A Jira admin runs the flag writing test again, then saves the project's setting. |
| An issue counts as blocked without a flag. | When tracking was turned on in the site's first project, the app saved the suggested signals (statuses whose name clearly means blocked, and “is blocked by”). Change them on the Signals tab; to count only the flag, clear every status and link and save. |
| Old blockers are gone. | They passed the project's retention period, 365 days by default. Check the project's retention setting. |
| Short blockers are missing after the license was inactive. | When the license is active again, the gap is filled from Jira's history up to 35 days back. Older short blockers cannot be rebuilt. |
| A blocker left the queue after its issue moved to another project. | The target project is not tracked, so the blocker stopped being followed at the move. Turn on tracking in that project too; if the issue comes back to a tracked project, tracking continues from Jira's history. |
| An owner's name disappeared. | The Atlassian account was closed, and the app removed every reference to it. This is a privacy obligation. |
Data requests
- Export: a Jira admin exports every stored record from the Data tab, as JSON Lines. We have no access to your data, so we cannot export it for you.
- Closed accounts: the app removes references to closed Atlassian accounts on its own, weekly.
- Uninstalling: Atlassian keeps the app's data for 28 days after removal; reinstalling does not restore it automatically. The app never removes flags from your issues.