nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Connect end of support: what to do about your worklog report before 31 January 2027

Druvis Cukurs (Lineset)

If your team's hours go into Jira as worklogs and come out through a reporting app, it is worth ten minutes this month to check what that app is built on. Atlassian Connect, the older way of building Cloud apps, reaches end of support on 31 January 2027. Reports are the part of the stack people notice last: nobody looks at the timesheet app until the month-end invoice or payroll run depends on it.

Here is what is happening, what it means for a worklog report, and a checklist for deciding what to do.

The timeline

17 September 2025: no new Connect apps accepted on the Marketplace (Atlassian's announcement).
May 2026: a notice, "This app might stop working soon", began rolling out in Connect apps' own screens, first in admin pages; since September every site with an app using Connect features sees it, end users included (developer community).
Late July 2026: admins see a yellow warning on the Connected apps page in Atlassian Administration for Connect-only apps and for vendors who said they will not move or have not decided; since September, a blue note for vendors who said they will (what admins see).
3 August 2026: end of support moved from December 2026 to 31 January 2027 (developer community).

What changes on 1 February 2027, and what does not

Connect apps do not switch off. In Atlassian's words, after the deadline "only critical security vulnerabilities will be addressed and Connect feature deprecations will happen with little notice", and breakages are expected to become more frequent (Atlassian, 3 August 2026). The same post says over 95% of paid app seats have already moved to Forge.

For a worklog report, the risk is not a hard stop. It is a report that fails one month-end, with no fix coming. The admin warning itself tells you what to do: "For migration plans or other available options, contact the vendor directly through the app's Marketplace listing." Atlassian does not publish a list of replacements.

A checklist for admins

List what is on Connect. In Atlassian Administration, open Connected apps for your site and read the note beside each app.
Ask each vendor. Use the support link on each app's Marketplace listing: is a Forge version coming, and when? A blue note means the vendor has said it will move. If the answer is a date before 31 January 2027, you may need to do nothing else.
Write down how the report is used, before anything changes: each saved report's period, grouping, split by day, week or month, the people or groups it covers, who it is shared with, and what is exported and where it goes. This is the part people forget, and the part that makes any move quick.
If you need a replacement, decide what you actually need. A report over Jira's own worklogs means nothing changes about how people log time, and nothing has to be migrated: the hours are already in Jira. If you need timers, approvals or locked periods, you need a time-tracking app, which is a bigger decision.
Check how it handles your data. The listing's Privacy and Security tab shows what an app may read and write. A Runs on Atlassian badge means no data leaves Atlassian (Atlassian).
Run old and new side by side for one closed month and compare totals per person and per work item before anyone relies on the new one. When two reports differ, it is nearly always the time zone that decides which day a worklog counts on, or worklogs restricted to a group or role that only some people can see.
Move before the deadline, not after. Rebuild the saved reports, share them as before, tell people where they are, and uninstall the old app once nobody opens it, while the old report still works if you need to check a figure.

If you only need a figure now and then

Jira can find the work items someone logged time on with JQL, for example worklogAuthor = currentUser() AND worklogDate >= 2026-10-01 AND worklogDate <= 2026-10-31. Be aware that the Time Spent beside each work item, on screen and in the export, is the work item's all-time total from every author, not the time logged in the period. Jira's own Time tracking report works per version in company-managed spaces (Atlassian), and a report of time per person per period is an open request, JRACLOUD-97253. For an occasional check that may be enough; for a weekly timesheet or a monthly invoice it usually is not.

What we built

Full disclosure: I'm the founder of Lineset, and we built Logline for teams in exactly this position, so weigh this part accordingly. It is a worklog report and timesheet app on Forge that reads Jira's own worklogs as the person viewing, changes nothing in Jira, and runs on Atlassian, so nothing leaves your site. If you bill from Jira, it adds billable hours and amounts at your rates. The two can run side by side while you compare.

A month of Jira's own worklogs in a space's Logline tab: rows by epic and work item, billable hours, estimates, and one work item opened to its worklogs.

https://marketplace.atlassian.com/apps/1363348776

Whatever you use, do the checklist before the month-end that matters. If you have already moved a worklog report off Connect, which total didn't match on the first run?

Comments

Marcin Nowak (Radrly)

Very useful checklist, especially step 3. Writing down how each saved report is actually used is the step that saves the most time later.

Two more things I'd add to step 6 when you compare old and new for a closed month:

Rates, not just hours. If the old report also turned hours into money, check which rate it applied to a worklog logged before a rate change. Some tools use today's rate for the whole history, others use the rate that was valid on the worklog date. The hours match and the invoice total still doesn't.
Where the hours come from. If part of the team logs time in Tempo, check whether those hours are synced to Jira as worklogs on your site. A report over Jira's own worklogs only sees what is actually there, so a missing sync shows up as a gap per person, not as an error.

And one note on step 4: it's worth asking whether you need only a report, or also budget tracking on top of it. Many teams that move off a Connect timesheet app find the real question at month-end was "are we over budget on this client?", not "how many hours did Anna log?".

Disclosure: I'm the founder of Radrly. We build MarginRadar, a Forge app that runs on Atlassian and turns Jira worklogs, including Tempo hours synced to Jira, into cost, budget burn and margin per space and epic, with rate cards per role. It focuses on the budget side, and it can run next to whichever worklog report you choose.

[External link removed.]

Druvis Cukurs (Lineset)

Thanks Marcin, both good additions to step 6.

Rates by date. Agreed, that's where the hours match and the invoice still doesn't. Logline (ours) applies the rate in force on the day each worklog counts on, so a new rate from 1 November leaves October's amounts as they were. Rates can be set by client, space or person.

Budget, not just hours. Also agreed that "are we over budget on this client?" is the real month-end question. That's why Logline answers it in the same report as the hours: budgets in hours or money, with cost and margin, by space, epic or client. When the month closes, each client's timesheet goes out as a PDF, or the billable lines as a file Xero or QuickBooks imports. One app, from the worklog to the invoice.

Hours synced from another time-tracking app. One detail worth checking: some write each worklog to Jira under their own app account rather than the person's. Any report over Jira's worklogs then sees the hours but not who logged them, so per-person totals look short while work item totals are right. Check it on one closed month before trusting a per-person figure.

Marcin Nowak (Radrly)

Thanks Druvis, and good catch on the app account. We see exactly that with Tempo Cloud: the worklogs synced to Jira are recorded under Tempo's app account, not the person's. So work item and space totals are right, but any per-person figure built on Jira's worklogs comes up short for those hours.

For anyone checking this on their own site, an easy test is to open one work item with Tempo time and look at the author on its worklogs in Jira. If it shows the app instead of a person, plan your per-person rates around that before you trust a per-person total.

In MarginRadar we handle it openly rather than guessing: those hours still count in spent, burn and margin, priced at the space default rate, and an admin can switch that to hours with no cost. Per-person rates apply only where Jira names the person. Rates also keep a dated history, so a rate change doesn't rewrite last month.

Different tools, same lesson as your step 6: compare one closed month before anyone relies on the numbers.

Caner Kaya -Kayabyte-

One addition to Marcin's check. If the author on the Jira worklog shows the app, the person's name usually still exists in Tempo: Tempo's own API returns the real author for each worklog. So per-person rates can work if the report reads from there, at the cost of an API token from a Tempo admin and a call outside Atlassian, which is worth raising with whoever signs off your apps.

Full disclosure: I make Burnrate, which does this as an optional connection, still in beta. It's built on Forge, so the Connect date doesn't affect it. Same advice as step 6 either way: compare one closed month first.

Mohammed Shakhib

Hi there,

The external link in your comment have been removed per our Atlassian Partners - Rules of Engagement. Partners may only link to the Atlassian Marketplace or Partner Directory–external site links are not permitted.

Thank you for your understanding!

Druvis Cukurs (Lineset)

We checked this ourselves in October: hours logged in the other app reach Jira under that app's own account, with its text in place of the person's comment. So before step 4 there is a choice to make.

Keep the report inside Jira. It reads only what Jira holds, so those hours count in every work item, space and client total, under the app's name, not the person's.
Connect the report to the time-tracking app's own API. The per-person figures come back, at the cost Caner named: a token from that app's admin, and your worklogs leaving Atlassian for a call outside it. Put that to whoever approves your apps before you choose, not after.

Logline, which I built, takes the first road on purpose: it runs inside Jira, with no servers, and changes nothing in Jira. Hours written under an app's account show under that account, and the space's or the default rate still prices them; a person's own rate applies wherever Jira names the person. If per-person rates matter for that team, the way to keep them inside Jira is to log with Jira's own Log work.

Either road, step 6 still holds: one closed month side by side before anyone bills from it.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

time-tracking

connect

forge

reporting

worklogs