Changelog
Most SyncUp updates install themselves and need nothing from you. A release that asks for a new permission waits for a Jira admin to approve it, and until someone does, your site keeps running the version it already has. An admin can review and approve a waiting release in admin.atlassian.com → your site → Apps.
Released 3 September 2026
Your Jira admin is asked to approve one new permission before this version applies.
- Usage analytics. SyncUp now records which features get used, so we know what to improve. It sends your site address and a few counters, such as which tab was opened and whether the sprint is still running. Your issues, your sprint names and your team members’ names are never included, and activity is recorded against your site rather than against individual people. Admins who would rather send nothing can turn this off in Atlassian Administration, and SyncUp keeps working exactly as before. See Configuration.
Improved
Section titled “Improved”- Alerts are now worked out for each person. Your alerts are built from the issues you can actually open, so an issue kept from you by an issue security level can no longer appear in your alerts. Alerts used to be calculated once and shown to the whole project, which meant a restricted issue’s key and summary could reach someone who was not allowed to open it.
- Dismissing an alert is personal, and it lasts. Dismissing used to hide an alert for everyone on the project, and it reappeared at the next refresh. It now hides the alert for you alone, and it stays hidden for as long as the condition describes the same thing.
- Sprint history is kept per project. A board shared between two projects no longer mixes their history, their snapshots or their reports.
- Sprint reading no longer stops part-way through a large sprint, so the figures cover every item rather than the first few hundred.
- Every action re-checks your subscription and your Jira permissions on the server, rather than trusting the page in your browser.
- A team member whose display name contained unusual characters could stop a sprint report from being produced at all. Reports are now generated whatever anyone is called.
- The unused Slack and Teams webhook fields were removed from Settings.
- Projects that no longer have a board are forgotten instead of being retried forever.
1.0.0 - Marketplace launch
Section titled “1.0.0 - Marketplace launch”Release date: TBD
The first public release on the Atlassian Marketplace.
Features
Section titled “Features”- Daily Brief tab with three role-specific views (Developer, Scrum Master, Product Owner).
- Sprint Health tab with a 0-100 composite score broken into five components (Progress vs Time, Blocked Items, Scope Stability, Team Balance, Velocity Trend).
- Reports tab with an automatically generated Sprint Autopsy for every sprint that closes while SyncUp is installed, plus a multi-sprint comparison view.
- Alerts tab with six alert types: Sprint Goal Risk, Blocker Aging, Scope Creep, Due Date Warning, Overload, Milestone.
- Settings tab for team-role assignment (admin), personal alert sensitivity, and optional daily email briefings (admin).
- Hourly snapshots of sprint state powering trends, scope-creep detection, and the final autopsy.
- Sprint Comparison across the last 5 closed sprints.
Privacy & security
Section titled “Privacy & security”- Runs inside Atlassian Forge, and your Jira data never leaves your Atlassian tenant.
- Sprint history and reports are stored inside your own Atlassian tenant.
- The single
write:jira-workscope is used only to create an internal “anchor” issue that Forge uses to deliver email notifications through Jira’s mailing system. SyncUp does not modify your team’s issues, comments, or workflows. - Read-only on everything else (boards, sprints, issues, JQL, users, projects).
- GDPR compliant. Full details on our privacy and security pages.
Known limits
Section titled “Known limits”These are current, deliberate limits rather than bugs:
- Totals count the whole sprint, including items you cannot open. The health score, the item counts, the forecast and the velocity figures are worked out across every item in the sprint. If an administrator has restricted an item so that you cannot see it, that item still counts towards those totals, so a total can be larger than the list of items shown to you. The restricted item itself stays hidden: its key, its summary and who it is assigned to are never shown to you, and never appear in your briefing email. Sprint health is a measure of the sprint, not of your own view of it, which is why the figures cover everything in it.
- Velocity is counted in items, not story points. A sprint of ten small items and a sprint of ten large ones read the same.
- The staleness thresholds are fixed. An item is chased after 5 days with no activity for Decisions Needed, and flagged red after 3 days in progress. You cannot change either.
- An alert can be dismissed, but not snoozed. Dismissing hides it for you alone, and it stays hidden while the condition describes the same thing.
- Sprints that closed before SyncUp was installed are not analysed. History starts at installation, so the first few sprint comparisons have less to compare against.