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.

4.13.0

Released 4 November 2026

This release installs itself and asks for no new permission.

Fixed

A saved sprint report now reaches only someone who can open every item it counted. A Sprint Autopsy report is written once, when the sprint closes, and it counts every item that was in the sprint. The Reports tab showed that report to anyone on the project, so its item counts, its breakdown by priority and its contributor list described work that an issue security level keeps from some of the people reading them. Before a report is listed, Jira is asked whether you may open each of the items behind it, and a report you may not see in full is left out of your list. The velocity trend on the dashboard and the Sprint Comparison table are built from the same reports and follow the same rule. A report is left out rather than narrowed, because it holds the totals and not the items they were worked out from.
The scope change alert no longer quotes a figure taken from the whole sprint. The alert used to name the sprint’s starting and current item counts, which are recorded hourly across every item in the sprint. Someone who could see only part of the sprint could compare those numbers with their own and work out how much was being kept from them. The alert is now shown only to someone whose own view covers the whole sprint.
A briefing is no longer built from an assumption about what you may see. When Jira could not answer which items a recipient may open, the daily briefing and the end of sprint summary used to fall back to the items assigned to that person. An issue security level applies to the item and not to the assignment, so an item can be assigned to someone the level excludes, and the fallback could then describe work Jira refuses to show them. If the check cannot be completed, that person’s email is not sent. The sprint still closes and its report is still written.

Changed

Reports saved before this release are not listed. An older report carries no record of which items it counted, so there is no way to ask Jira whether you may open them, and it is withheld from everyone rather than shown without the check. Report history starts again as sprints close from now on, and the velocity trend and the Sprint Comparison table fill back in at the same rate.

4.12.0

Released 4 November 2026

This release installs itself and asks for no new permission.

Improved

Clearer wording in alerts, emails and settings. Nineteen places where SyncUp wrote to you used a long dash to join two thoughts, in the daily briefing, the sprint summary email, the alert messages and the Settings labels. They now read as plain sentences. Nothing about what SyncUp tells you has changed, only how it is written.

4.10.0

Released 4 November 2026

This release installs itself and asks for no new permission.

Fixed

A sprint that is past its end date now says so. Jira does not close a sprint when its end date arrives, so an active sprint can keep running well past it. SyncUp used to carry on counting the days up, so a 28 day sprint could read “Day 99 / 28” alongside “0 days left”, and the health score treated it as though it were on its final day. The day counter now stops at the length of the sprint, the dashboard and the daily briefing say how far past its end date the sprint is, and a sprint that is overrunning is no longer reported as Healthy. A sprint whose work is finished is not marked down for waiting to be closed, and the score of a sprint that is still running is unchanged.
The Score Breakdown panel adds up again. When a sprint is overrunning, the points it loses for that now appear as their own row in the panel, so the rows account for the score above them.

Changed

Health history shows a step for sprints that were already overrunning. The health score is recorded every hour and kept as history. For a sprint that was already past its end date before this release, the figures recorded from now on are lower than the ones recorded before it, so its health trend shows a step down at this point. Sprints that start after this release are unaffected.

4.9.0

Released 4 November 2026

This release installs itself and asks for no new permission.

Fixed

Every project now gets its turn. On a site with many projects, the hourly collection worked through the list in a fixed order and whatever did not fit in one run was left out, every hour. A project could therefore go without sprint history and without its daily briefing indefinitely, with nothing to show why. The list is now ordered by which project waited longest, and the collection has more time to work through it.

4.7.0

Released 4 November 2026

This release installs itself and asks for no new permission.

Improved

SyncUp answers a little sooner. Usage reporting used to happen while you waited, so a slow moment at the other end could be a slow moment for you. It now happens after your request has already been answered. Nothing about what is reported has changed.

4.6.0

Released 4 November 2026

This release installs itself and asks for no new permission.

Improved

The end of sprint summary is now written for each person who receives it. Everyone still gets a summary of the same sprint, but the counts, the contributor list and the breakdown by priority now cover only the work that person is allowed to open. People whose access to some issues is restricted will see smaller numbers than before, which is the point: the figures used to be worked out from the whole sprint and sent to everybody.
When someone cannot see the whole sprint, their summary leaves the health trend and the scope change figure out rather than showing a narrowed version of them. If we cannot confirm what a person is allowed to see, their summary covers just the work assigned to them.
The dashboard sends your browser less. Your e-mail address, your avatar and the name of a board shared with another project are no longer part of the answer. Nothing on screen changes.
Role assignments are checked against the people Jira lists on the project, and are limited to 200 at a time. A rejected save now tells you why instead of quietly reverting.

Changed

“Send test” can be used once every fifteen minutes per project, and it now follows the main notification switch. With notifications switched off for a project, no test is sent and the button says so rather than reporting success.
Usage analytics now records when SyncUp is opened and which tab is being viewed, and carries the app version and whether the site’s subscription is active. Your issues, your sprint names and your team members’ names are still never included, and the record is still kept against your site rather than against individual people. An admin can switch it off in Atlassian Administration as before. See Configuration.

Fixed

A subscription that Atlassian reports in either of the two ways it can is now recognised, so a valid licence cannot be read as expired.
Alerts you dismiss are recorded only when the dismissal really applies to an alert.
A screen that no longer existed in the app has been removed from the server as well.

4.0.0

Released 3 September 2026

Your Jira admin is asked to approve one new permission before this version applies.

New

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

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.

Fixed

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

Release date: TBD

The first public release on the Atlassian Marketplace.

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

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-work scope 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

These are current, deliberate limits rather than bugs:

Figures cover the work you can open, not the whole sprint. The health score, the item counts, the forecast and the velocity figures are worked out from the items Jira lets you open. Where an administrator has restricted an item, it is absent from your figures, so two people looking at the same sprint can see different totals, and 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. A figure that was worked out across the whole sprint and cannot be narrowed to your view, such as the health trend or the scope change percentage, is left out for you rather than shown.
A report’s planned count and health trend come from the hourly record of the sprint. They are taken from the snapshots collected while the sprint ran rather than from the items the report ended with, so an item that was in the sprint earlier and removed from it before the sprint closed still counts towards them.
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.