Guidance on time tracking across two Jira instances (TimeCamp)

[James Hamm]

We use Jira Cloud with TimeCamp to track time per issue. For a current engagement, the issues live in our partner agency’s separate Jira Cloud instance. TimeCamp appears to allow only one Jira integration per workspace, so our team can’t start timers tied directly to the agency’s issues.

Could you recommend an Atlassian-approved approach to keep per-issue time tracking while the source of truth remains in the agency’s Jira?

We’re considering:

• Jira↔Jira mirroring/sync into a project in our instance (so our team tracks time on the mirrored issues that TimeCamp can see). If this is the best practice, which Marketplace apps do you recommend, and do they require installation on both instances? Any gotchas around fields, comments, attachments, or status mapping?

• Atlassian Automation or other native options for cross-instance issue creation/updates (lightweight “stubs” in our instance) — is this feasible/recommended?

• Alternative time-tracking add-ons (e.g., Tempo, etc.) that might better handle cross-instance scenarios.

Constraints/requirements:

• Keep the agency’s project as the single source of truth.

• Minimize overhead for engineers (start/stop timers from issues they’re already working in).

• Clean reporting on our side (ideally keeping a reference to the original issue key).

If you can point us to recommended apps, docs, or a configuration pattern — or set up a quick call — that would be great. 

[Sarah Hempel_Tempo_]

Hi @James Hamm, Tempo does have start/stop timers on the issue. Open the issue, hit "Start Tracker" from the More menu, and it runs in the background. When you stop it, the Log Time form pre-fills with your time. So the overhead concern is real. But timers aren't the gap here.

On worklog attribution: Tempo writes a corresponding entry to Jira's native worklog API, but that entry is anonymized on the Jira side. Tempo's own records carry full author attribution. If your sync app needs author data, pull from the Tempo API instead of the Jira API. It returns worklogs with complete author details.

If the agency is open to installing Tempo on their side, you'd skip the sync complexity entirely. Unified reporting across both instances, no Jira worklog layer involved.

If it'd help to see the Tempo API docs or get into the cross-instance setup specifics, just say so.

Disclosure: I work for the team behind Tempo.

[Matthias Gaiser _K15t_]

Hey @James Hamm

welcome to the Atlassian Community.

I'm Matthias from the team behind Backbone Work Sync and can comment from the other angle from what @Anton from JetHeads_io wrote.

I'd also recommend the same base setup:

1. Jira↔Jira mirroring/sync - either via Automation or a specialized syncing app
2. Jira/Time Tracking apps - I'd also look mainly for a solution which writes Jira worklogs. Then it's easiest for syncing apps or Automation to pick up the worklogs and sync them.

I'll share my thoughts about these setups in more detail:

1. Jira↔Jira mirroring/sync

Automation

Implementing via Automation is possible, but it's quite cumbersome. If you want to go that way, you need multiple rules in both Jira instances:

• When an issue is created, create it in the other Jira
• When an issue is updated, update it in the other Jira
• When work is logged, create a worklog in the other Jira
• When a worklog is updated, update a worklog in the other Jira

I'd recommend checking out the issue and worklogs REST API, as well as the Work item created, Work item updated and Work logged automation triggers. If you want to implement updates, you need to make sure to write the issue key of the other Jira into a custom field or issue property and the worklog id of the other side maybe into a worklog property, or similar, so that you can update them later.
Besides the manual setup and maintenance work, I see the main drawback that it's still not possible to my knowledge to sync attachments this way.

Syncing App

A syncing app takes away the burdens of how to correlate the worklogs and/or issues - and all the maintenance work. You configure some rules which fields/attachments/comments and of course, worklogs, you want to sync and they're synced. I'm mainly speaking for Backbone here, but the other apps follow the same principle.
This documentation article goes into more details how to setup/configure worklog sync with Backbone, e.g. if you want to include the actual author or anonymize it.
You can sync the original issue key either into a custom field in your instance or see it in a sync panel on the issue which most syncing apps provide.

When it comes to installing apps, yes in general you need to install the apps on both involved instances - and then either configure it on both ends or on one end only. Backbone offers the configuration on one side only, and with our remote license we also make it possible that you install the app only in one Jira instance. You can find a more detailed explanation of Backbone's licensing models in our docs.

2. Jira/Time Tracking apps

That's where I'll leave it more to the time tracking specialists. As far as it involves the syncing, the main requirement is to have actual Jira worklogs - and not only worklogs in the database of the time tracking app.

One addition maybe to what @Anton from JetHeads_io wrote: You need to decide if you need the actual author of the worklog in the other system. Most of the times we heard from our clients that syncing with other companies often requires stripping away the actual user who logged time makes it easier in terms of following GDPR requirements. If you want the author, then it's better to have the author on the worklog (which is not the case for Tempo).

About a quick call

If you want to discuss a solution with Backbone further, head to our product page and schedule a demo there. Ideally include a link to this discussion, then we have the context already.

[Anton from JetHeads_io]

Hey James! 👋

You've actually got two separate problems tangled together here, and they're easier to solve once you split them.

1. Jira-to-Jira sync (the source-of-truth side). This is its own thing — mirroring the agency's issues into your instance so your team has something local to work against. There are solid Marketplace apps built specifically for cross-instance sync, but I'll be honest: I don't run these day to day, so I won't hand you a recommendation I can't back from real experience. Worth a fresh, focused question on that alone — the sync vendors will jump in, and Martin's point above about user mapping being the hard part is exactly the right thing to pin them on.

2. How you log the time — this is where the details make or break the sync. Whatever tracker you pick on the side that syncs, it has to log time in a way the sync app can actually carry across. Two things matter most:

• It must write native Jira work logs — real entries on the issue via Jira's own work log API, not time parked in the app's own private layer. A sync app can only pick up what actually lives on the Jira issue.
• The real author has to be on the work log — the person who did the work, as the native Jira author. If the tracker hides who logged it, your reporting on the other side loses the one thing you need: who spent the time.
• Timers, since your engineers work from the issue — start/stop on the issue they're already in, then it becomes a real work log. That keeps the overhead you're worried about near zero.

This is worth checking carefully, because it rules some options out. Tempo does its job well — but for this exact setup it's not the fit: it keeps time in its own worklog layer rather than as native author-attributed Jira work logs, and it has no start/stop timers on the issue.

The combination you actually want — native work logs + real author + timers — is what JetTime (a third-party Jira app) is built around. Every log is a native Jira work log attributed to the real author, and timers start right from the issue — so a sync app has clean, correctly-authored data to pick up.

Practically: you'd install it on the agency's Jira (the source of truth) so the work logs land natively there. If you also want richer reporting on your own side — group and roll up by user, date, account, custom fields — you can run it on your instance too.

• Start/stop timers from the issue, log straight into a native Jira work log
• Real author on every work log — nothing hidden
• Reports and worksheets: filter, group, roll up by user/date/account/custom hierarchies etc, export
• Runs on Atlassian — your data stays inside Atlassian Cloud, we don't have access

Happy to jump on a quick call if it helps — just on the JetTime side (setup or a quick demo), not the sync piece, since that's genuinely not my wheelhouse. You can reach me by anton@jetheads.io

👉 JetTime on the Atlassian Marketplace

— Anton, JetTime founder

[Martin Runge]

Hi @James Hamm

There are 3-4 apps managing your challenge. The main difference is installation: some need the app on both instances, others run on one site or outside via REST API and don't require installation on the agency's site. User mapping is the main issue, regardless of the method. Your solution should allow mapping your user to a different or shared agency user, preventing the need to add logins for non-workers.

Native Automation works well when paired with a Send web request to directly call the other instance's API; it's like creating your own sync system, rather than relying on a pre-existing, supported solution.

Are you able to install on the agency's Jira instance, or is that not an option? This helps us determine which solution will work best for you.

Cheers, Martin