Troubleshooting: Common Questions & Quick Answers

Common questions

Why do the numbers differ from Jira or another chart?

Short answer: this is usually expected when the data source, time range, estimate, issue scope, or calculation differs. Compare like with like before treating it as a defect. Confirm the same board or JQL source, selected sprints or date range, issue types, estimation field, and chart settings. Check issue history for work added, removed, re-estimated, completed, moved, or reopened during or after the sprint. For Velocity, compare the intended metric: Initial Commitment is the scope in the sprint when Start sprint is clicked; Completed Work is work completed by the end of the sprint; Not Completed Work is unfinished scope; Rollover is work carried from the preceding displayed sprint. These are not interchangeable totals.
Contact support when: the discrepancy remains with the same configuration. Include representative issue keys, both screenshots, and the app and Jira versions.

Why is Rollover empty, or why does Initial Commitment look unexpected?

Short answer: Rollover counts issues carried directly from one displayed sprint to the next. It uses the chart timeline and Sprint Filter, not the board configuration alone. Confirm that the expected previous and current sprints are both included in the chart’s Sprint Filter. Check that the issue moved directly between those selected sprints. Check the estimation field and the Exclude from Rollover configuration. Excluded statuses apply only when the issue was already in that status at sprint start. Contact support when: an issue was carried directly across the selected sprints and is still absent from the Rollover issue list.

Why is a Velocity metric above 100%?

Short answer: it is normally expected. Percentage view is a ratio, not a cap. A metric can exceed 100% when it is greater than the selected ratio basis, for example if work was added during the sprint. Check whether the ratio basis is Initial Commitment or Final Commitment. Confirm the estimation field, selected sprints, and scope changes.

Why is a chart empty, slow, or failing after an update?

If the chart is empty, first check the chart configuration and data:

1. Check the data source. Confirm that the selected board, project, filter, or JQL currently returns issues that the viewer can access.

2. Check the chart scope. For sprint-based charts, make sure the intended sprints are selected and contain matching issues. For date-based charts, verify that the selected period includes relevant issue activity.

3. Check issue filters. A JQL, issue-type, status, sprint, or other chart filter may exclude every issue from the selected data source.

4. Check estimation field. Make sure the field used by the chart has values on the matching issues. For board data sources, a board-specific estimation-field setting can override the field selected under Calculation.

5. Check permissions. The viewer must be able to access the board, project, filter, and underlying issues. Where supported, test a smaller known-good data source.

If the chart is slow or fails after an update, also confirm the app version and, for Data Center, documented compatibility with the Jira or Confluence version. Refresh the page and determine whether the problem affects one user or multiple users. On Data Center, also check whether it affects one node or all nodes.
Contact support when: the problem persists or affects multiple users. Include the exact error, version and requested HAR or support data.

Why does a chart not work in Confluence, or why did editing it change the dashboard?

Short answer: an embedded chart is a Jira Smart Link to the original dashboard gadget. It remains live, and saved edits made through the Smart Link also change the original gadget. Confirm that the viewing user can access the Jira source and that the Smart Link points to the intended gadget. If a copied or moved Confluence page shows an unexpected chart, check the linked gadget and its configuration; the copy does not create independent chart settings. If a user can view but cannot edit, verify their Jira dashboard/gadget permissions and their access to the underlying Jira source. Contact support when: the Jira–Confluence connection cannot be authorized or the embedded chart keeps loading. Include exact error, deployment, and requested HAR.

How do I configure Cycle Time for my workflow?

Short answer: configure the timer to match the workflow you intend to measure; do not assume the first and last workflow statuses are the right boundaries. Choose the relevant data source and calculation. Set Start timer on to the intended In Progress status or statuses and Pause timer on to the intended Done status or statuses. When a single status is selected, choose the required first or last transition rule.

Why does a Time in Status group not equal the sum of the individual status averages?

Short answer: this is expected for grouped statuses. The app sums the selected statuses for each issue first, then applies the chosen statistic to those issue totals. Confirm the selected statuses, status groups, date range, statistic, work schedule, and calculation method. Use the issue list to validate a small sample of issues and their transition history.
Contact support when: the status mapping, time range, grouping, and representative issue history still produce an unexpected result.

Why does a Burnup or Burndown forecast show an unexpected completion date or number of sprints?

Short answer: a forecast is a projection, not a commitment. It changes with the input assumptions and current scope. Check scope, selected scenario, forecast start date, sprint cadence, completed/current-sprint treatment, velocity assumptions, and scope-growth assumptions. State the expected date or sprint count and why it should differ.

Can I migrate saved reports from Data Center to Cloud with JCMA?

Short answer: migration support is product- and version-specific. For Velocity Charts, automatic app-data migration is supported from Data Center version 7.1.0 when the Cloud app is installed and required Jira dependencies are included. Run a test migration before production. Include referenced dashboards, filters, projects, and custom fields with or before app data. Ensure the required Cloud permissions are present, including the permission to share dashboards and filters for the app’s administrative group. Keep a before/after inventory and migration logs. If migration runs are split, migrate Velocity Charts app data once—preferably in the final run or after Jira data is available. Contact support when: a supported, tested migration still has missing or incomplete charts. Include logs, source and target versions, and missing dependencies.

Can I export chart data, automate it, use an API, or obtain usage analytics?

Short answer: these are different requests. First decide whether you need a chart snapshot (PDF/PNG), chart data (CSV where supported), scheduled extraction, issue-level data, REST API access, dashboard/gadget inventory, or interaction analytics. Use the built-in export for the specific chart when it is available. Do not infer API availability from what appears in the UI. For an unsupported request, provide the target chart, required fields, cadence, destination, deployment, and business purpose.

What to include in a support request

Include app and version; Cloud or Data Center; chart type; JQL source and permission context; chart configuration and estimation field; affected sprint, date range, or statuses; expected versus actual result; screenshots; and representative issue keys. For failures, include the exact error and time plus requested HAR or support data.