Overview
An audit trail is a chronological record of all key actions performed within the system. It shows who did what, when, and where, helping you track changes and activities in your Harness account.
Audit trails are automatically generated and cannot be altered, keeping the information accurate and reliable. This information can be used during compliance or to help identify and resolve issues more quickly.
Before you begin
Viewing the audit trail
The audit trail can only be viewed at the account and organization scope. Audit events for the account scope do not appear in the audit trail at the organization scope.
To view the audit trail at the account scope (for organization scope events, go to the Organization Settings), follow these steps:
-
In Harness, go to Account Settings.
-
Navigate to the Security and Governance section, then click Audit Trail.
-
The Audit Trail page opens, showing audit logs from the past 7 days by default.
Each record logs an activity that happens within the system. These records may take a few minutes to appear in the Audit Trail. If you still can't see an event, try refreshing your browser.

Filter by date and time
Limit the audit events displayed to a specific time range, from 1 day up to 2 years. Use the date picker to select the exact start and end dates, including the time of day.

Audit trail types
By default, all audit events are displayed. You can refine the records using the following filters:
- Exclude Login Events: Hides authentication-related events, such as successful or failed logins, 2FA, and so on from the records.
- Exclude System Events: Hides events generated by the system.

Add a filter
To add a filter, perform the following steps:
-
In Account Audit Trail, click the filter icon.

-
In the New Filter settings, select filters to refine audit events. Narrow the viewable events by adding filters and selecting:
-
User
-
Organization
-
Project
-
Resource Type
-
Resource Identifier
-
Action
noteThe Resource Identifier operates in conjunction with the Resource Type. It allows you to use the resource identifier to filter audit events related to a specific resource using that identifier.
Infrastructure Audit TrailTo retrieve the infrastructure audit trail, use the Environment resource type and provide your environment identifier as the Resource Identifier.
-
-
In Filter Name, enter a name for your filter.
-
For Who can view and edit the filter?, select Only me or Everyone based on the visibility you want to set for this filter.
-
Select Save to create a filter.

-
Select Apply to view the audit events as per the filter you just created.

By default, the events of the last 7 days are returned for the filter. To view more results, you can select the date range accordingly.
Audit trail data fields
The data fields capture the information for each audit event, including the user, action, time, and affected resources.
- Time: The date and time when the activity occurred.
- User: The user who performed the action (typically shown as an email ID or username).
- Action: The action that was performed (created, updated, deleted and so on).
- Resource: The Harness entity that was affected by the action.
- Organization: The organization name corresponding to the affected entity, if applicable.
- Project: The project name corresponding to the affected entity, if applicable.
- Module: The module corresponding to the affected entity (pipeline, Platform and so on).
- Event Summary: A detailed summary of the event, highlighting the changes made, along with the corresponding YAML differences.

By default, the Audit Trail does not capture pipeline execution events such as Pipeline Start, Pipeline End, Stage Start, and Stage End. To capture these events, enable the Enable Pipeline Execution Audit Events setting under the pipeline category in account scope settings.
This setting is available only at the account scope.
Audit trail for events
Audit trail are stored for up to 2 years. If you need to retain them for a longer period, you can use audit log streaming to export logs externally.
Audit logs capture key activities performed in your account. For example, when a new user is added, an audit log records the action (created, updated, revoked, etc.) along with relevant user details.
This is not an exhaustive list, as audit logs are generated dynamically based on user and system activities.
Module categories and resources
| Modules Category | Resources | Description |
|---|---|---|
| Platform Core |
| Core platform entities used to manage accounts, projects, users, access control, and authentication across Harness. |
| Continuous Delivery |
| Resources used to define, configure, and execute application and database deployments. |
| GitOps |
| GitOps resources for managing clusters and applications using Git as the source of truth. |
| Delegates |
| Delegates enable secure connectivity between Harness and customer infrastructure to execute tasks. |
| Secrets Management |
| Secure storage and management of sensitive values such as secrets and certificates used by pipelines and services. |
| Connectors |
| Configurations that allow Harness to integrate with external systems such as cloud providers, Git, and artifact registries. |
| Dashboards |
| Visual dashboards and folders used to organize and display insights and reports across modules. |
| Governance |
| Policies and policy sets used to enforce standards, compliance, and guardrails across the platform. |
| File Store |
| Files and variables stored in Harness and referenced during pipeline execution and configuration. |
| Platform Settings |
| Account-level and platform-wide settings that control security, notifications, branding, and integrations. |
| Resilience Testing (Chaos Engineering) |
| Resources used to design, run, and govern chaos experiments to validate system resilience. |
| Security Testing Orchestration |
| Security testing targets, exceptions, overrides, and ticketing artifacts for managing security findings. |
| Cloud Cost Management |
| Cost visibility, optimization, anomaly detection, and governance resources for managing cloud spend and efficiency. |
| Feature Flags |
| Feature Flags resources used to control feature rollout and targeting. These audit events apply to Feature Flags resources, not FME entities. |
| Code Repository |
| Source code repositories and governance rules for managing code changes and integrations. |
| Internal Developer Portal |
| Developer self-service portal resources including service catalog, workflows, scorecards, and integrations. |
| Supply Chain Security (Software Supply Chain Assurance) |
| Artifact and component-level compliance data for securing the software supply chain. |
| Infrastructure as Code Management |
| Workspaces and modules used to manage infrastructure using infrastructure-as-code workflows. |
| Artifact Registry |
| Artifact registries and upstream proxies for storing and serving build artifacts. |
| Release Management |
| Release orchestration resources used to model and manage release processes and workflows. |
| Other / System |
| System-level, licensing, and miscellaneous resources used internally or across multiple modules. |
| Software Engineering Insights (1.0) |
| Metrics, insights, and configurations used to analyze software delivery and engineering performance. |
| Continuous Error Tracking |
| Error tracking resources used to capture, filter, and analyze application runtime issues. |
| Cloud Development Environments (Gitspaces) |
| Cloud development environments used to provision and manage Git-based workspaces. |
| Service Reliability Management |
| Resources for monitoring service health, defining SLOs, tracking downtime, and sending reliability notifications. |
Resource type and supported actions
Each resource in Harness can perform specific actions that reflect how it is created, updated, executed, accessed, or governed across the platform.
| Resource Type | Supported Actions | Description |
|---|---|---|
| All Resources (Generic) |
| Core lifecycle actions applicable to most resources across Harness. |
Access & Identity Resources (USER, ROLE, SERVICE_ACCOUNT, TOKEN) |
| Actions related to managing users, access, and authentication credentials. |
| Platform Authentication |
| Records authentication activity for users and service accounts. |
Pipeline Resources (PIPELINE, STAGE, INPUT_SET) |
| Actions that track pipeline and stage execution lifecycle. |
| Governance & Policy Resources |
| Actions that reflect policy state changes or controlled overrides. |
Git-Backed Resources (GitOps, Code, IACM) |
| Actions related to Git synchronization and source-controlled changes. |
| SLO & Reliability Resources |
| Actions associated with SLO and reliability management events. |
| Feature Flags Resources |
| Actions indicating Feature Flags state changes. These actions do not apply to FME entities. |
| Impersonation |
| Tracks when an identity assumes or exits impersonated access. |
| Tickets & Exceptions |
| Actions representing exceptions, alerts, or external ticketing outcomes. |
| System & Compliance Events |
| One-time or system-level events recorded for audit and compliance. |