How to Investigate a User's Activity Across Jira, Confluence, and Bitbucket

Three situations send an admin hunting through Atlassian activity data, and they always arrive without warning:

• Offboarding review — a departing employee's last two weeks: what did they access, export, or change?
• Security incident — a compromised account: what did the attacker touch, and in what order?
• Compliance spot-check — an auditor picks one contractor and says, "walk me through their access and actions."

All three need the same artifact: one chronological timeline of a person's actions across every product. And it's exactly what Atlassian Cloud doesn't give you out of the box.

Why this is hard with native tooling

Start from the end goal and the obstacles become visible:

1. The data lives in four places. Jira, Confluence, Bitbucket, and JSM each have their own activity surfaces and APIs. An investigation means four browser tabs and a spreadsheet.
2. Identity is fragmented. The same human is an accountId here, a display name there, a Bitbucket UUID elsewhere. Stitching these by hand is slow and error-prone — and an error in attribution is the worst possible mistake in a forensic context.
3. History evaporates. Native activity views are designed for "what happened recently," not "reconstruct March." If you didn't collect the events when they happened, they may be gone when you need them.

That third point is the hidden factor: investigation capability is something you set up before the incident, not during it. The collection pipeline has to already be running.

The setup: continuous collection into one store

AtlasLens (open source, Apache 2.0, self-hosted) continuously pulls audit and activity data from all four Atlassian Cloud products into a single MongoDB store, with cursor-based incremental sync and idempotent upserts — so events are collected once, kept for a year (TTL-enforced), and never duplicated.

Crucially for investigations, it performs identity resolution: account IDs from every product are resolved to one person, and group/team membership is resolved alongside. The question changes from "what did accountId 5f8a… do in Jira and was that the same person as this Bitbucket commit?" to simply "show me Alex."

To see the workflow before connecting anything real, the demo stack seeds ~4,000 synthetic events across 12 people and 4 teams:

docker compose -f docker-compose.demo.yml up --build
# open http://localhost:8080  →  admin / atlaslens-demo

The investigation workflow

1. Start wide: the Security & Forensics view

Before focusing on a person, scan for what's abnormal: permission and group changes, sensitive operations, spikes in the event-volume timeline. Every chart honours the active filters — product, date range, user, group, operation, category, severity — so narrowing from "last 90 days, all products" to "this user, sensitive ops only" is a few clicks, not a query language.

2. Focus: the User Timeline

Open the person's timeline and you get their actions across Jira, Confluence, Bitbucket, and JSM in one chronological stream. For an offboarding review, set the date range to the notice period and read it like a story. For an incident, anchor on the first suspicious event and walk forward — the cross-product view is what reveals the pattern a per-product view hides (a permission change in Jira, then unusual Confluence exports, then a Bitbucket clone).

3. Corroborate: the Work Items view

Activity events tell you that something happened; the Work Items view shows the artifacts — the person's tickets, pull requests, and pages, each deep-linked back into the source product so you can inspect the actual content.

4. Document: stamped exports

Investigations end in a report. The Reports & Export view produces CSV or PDF of exactly the filtered view you examined, stamped with the event count, a SHA-256 integrity hash, the filter criteria, and a timestamp. If the finding is challenged later, the export proves what was reviewed and when.

Handling the privacy dimension

A tool that can reconstruct a person's work history demands care. AtlasLens's posture, worth understanding before you deploy it:

• Admin-only by design — there is no signup page; admin accounts are provisioned deliberately via CLI, with bcrypt-hashed credentials and JWT auth.
• Field-level encryption — email identifiers are encrypted at rest.
• Bounded retention — events expire after one year via a MongoDB TTL index; the store is append-only.
• Self-hosted — the data never leaves infrastructure you control.

Pair the tooling with policy: define who may run an investigation, on what grounds, and with what oversight. The integrity-stamped exports support that governance — they make reviews auditable, too.

Known limits, stated plainly

Without Atlassian Guard, sign-in events and Bitbucket audit logs are not available from Atlassian's APIs — Bitbucket contributes activity data only (commits, PRs), and the Security view flags the sign-in gap explicitly rather than papering over it. If authentication forensics are a hard requirement, see our companion guide on auditing Atlassian Cloud without Guard for how to weigh that decision.