What is the ‘Last seen’ timestamp in Atlassian Administration?

'Last seen' helps organization and site administrators understand when a user was most recently active in supported Atlassian Cloud products. This timestamp serves as a guide to monitor active adoption and optimize license allocations.

Understanding the ‘Last seen' timestamp

Last seen records the most recent date a user performed a qualifying, interactive activity within an organization’s Atlassian apps. Updates typically appear in near-real-time but can take up to 24 hours to synchronize.

Where ‘Last seen’ can be viewed

  • Users list: the Last seen column shows the user’s most recent activity rolled up across all eligible usage. The users list is accessible via admin.atlassian.com, then select Directory, and then Users from the left sidebar, and review the Last seen column.

  • User profile: the Last seen column shows the user’s most recent activity for eligible usage for each supported product. To view ‘last seen’ within a user’s profile, select Directory, and then select Users on the left sidebar in Atlassian Administration, then select a user’s name in the User column. You can review the Last seen column per app via the Apps tab in the user’s profile.

Last seen vs Audit Log
Last seen is a lightweight indicator of activity rather than an audit log. For a comprehensive, timestamped record of administrative actions, user logins, and security events, refer to the Audit Log (Track organization activities from the audit log) which is available with Atlassian Guard or Enterprise plans.

‘Last seen’ coverage

Activity coverage

Last seen tracks most web, mobile and developer tooling activity, but doesn’t yet capture all activity as shown in the table below.

Activity type

Updates Last seen?

Description

Interactive web sessions

Yes

Active page navigation, viewing, creating, or editing content across supported web applications (active tab session ≥ 2 seconds).

Mobile applications

Yes

Interactive user sessions within supported mobile apps (Jira, Confluence, Jira Service Management, Trello, Loom).

Developer tooling (Bitbucket)

Yes

Git operations (git push, git pull, git clone via SSH or HTTPS) performed in Bitbucket Cloud workspaces.

APIs, tokens, & scripts

No

Programmatic calls via REST APIs, Personal Access Tokens (PATs), or custom backend integrations without an interactive browser session.

Automated workflows & webhooks

No

Background automation rules (e.g., Automation for Jira), scheduled jobs, or system-triggered webhooks.

AI & Agentic interactions

No

Automated queries or operations executed through AI assistants, Rovo agents, or external MCP clients.

Email replies & approvals

No

Creating issues, replying to notifications, or approving requests directly from email without opening the web interface.

Product and role coverage

As a general rule, Last seen tracks usage from licensed, billable users. Free and guest roles generally don’t record ‘Last seen’:

  • Standard product seats (Jira, Confluence, Loom, Bitbucket, Trello, Assets, Focus, Talent, Statuspage): Licensed users and product admins actively using the product update the timestamp.

  • Jira Service Management (JSM):

    • Licensed Agents and Admins: Update Last seen.

    • Portal Customers and Stakeholders: Helpseekers accessing the customer portal and free stakeholder seats do not record Last seen.

  • Jira Product Discovery (JPD):

    • Creators: Licensed creator seats update Last seen.

    • Contributors: Free contributor seats do not record Last seen.

  • External Collaborators & Guests:

    • Confluence Guests: Interactive guest sessions update the Confluence timestamp.

  • Administrative Roles:

    • The User Access Admin role does not record product-level Last seen activity unless the user also holds a standard licensed product seat.

A note on ‘Last seen’ for Jira:

Jira, Jira Service Management, and Jira Product Discovery have common platform services and navigation. Interacting with shared Jira components may be shown in Jira ‘Last seen'.

Reviewing and exporting timestamps for license reclamation

Viewing in Atlassian Admin

  1. Sign in to Atlassian Administration at admin.atlassian.com.

  2. Select your organization.

  3. Select Directory, and then Users on the left sidebar.

  4. Check the Last seen column for each user. This column provides the most recent activity rolled up across all supported apps.

  5. Select a user to view their Profile details and check individual app timestamps.

Best practices for license reclamation: Cross-check with users or team leads before revoking licenses, as users active solely via APIs, integrations, or mobile apps can show an older timestamp or an ‘unavailable’ timestamp.

Filtering and auditing inactive users

While the Directory provides a rolled-up view, exporting a user list allows you to filter and segment users based on specific inactivity thresholds (for example, >30, 60, or 90 days).

  1. Sign in to Atlassian Administration at admin.atlassian.com and select your organization.

  2. Select Directory, and then Users on the left sidebar.

  3. Select Export users.

  4. Choose your export criteria (including specific products or all users) and confirm.

  5. Download the CSV file sent to your email.

  6. In your spreadsheet tool, filter on the product-specific last active columns (e.g., Last active in Jira Software, Last active in Confluence) to identify candidates for license reclamation.

Reviewing timestamps via API

Organizations can automate user activity auditing and integrate with identity/ITSM tooling by querying the Organizations REST API.

Best practices for license management

  • Evaluate per product: Always review product-specific timestamps on the Product access tab before revoking access. A user may be inactive in Jira while remaining an active daily contributor in Confluence.

  • Account for API- and email-heavy workflows: Developers, integrations, or triage leads whose primary interactions occur via API tokens or email replies may show older timestamps despite ongoing reliance on Atlassian services.

  • Cross-reference before deprovisioning: Communicate with team leads or cross-reference your internal HR status to confirm if prolonged inactivity corresponds to extended leave, role changes, or completed projects.

 

Still need help?

The Atlassian Community is here for you.