> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Audit Log for compliance and change tracking

> Track configuration changes, integration updates, and incident actions in Rootly with a filterable audit log and JSON:API export for compliance evidence.

## Overview

Rootly's Audit Log captures every create, update, and delete action across your organization — configuration changes, integration updates, incident actions, workflow edits, role assignments, and more. Each entry records who made the change, what changed, when, from where (web, API, mobile, Slack, SCIM, OAuth), and the exact before-and-after values of the modified fields.

Built on PaperTrail under the hood with \~60 resource types instrumented, the audit log is the compliance evidence layer SOC2 and ISO27001 auditors look for. It's also a real operational tool — answer "who deleted this severity?" or "when did the escalation policy change?" without paging anyone.

<CardGroup cols={2}>
  <Card title="Full Change History" icon="clock-rotate-left">
    Every create, update, and delete across configuration, integrations, incidents, workflows, and on-call settings. Captures before-and-after field values.
  </Card>

  <Card title="Filter And Drill Down" icon="filter">
    Filter by date range, user, source (web/API/mobile/Slack/SCIM/OAuth), item type, action, or API key. Click any row to see the full diff.
  </Card>

  <Card title="JSON:API Export" icon="code">
    Pull audit events programmatically via the public API — useful for compliance archival, custom dashboards, and scheduled exports into long-term storage.
  </Card>

  <Card title="Sensitive Field Redaction" icon="shield-keyhole">
    Passwords, tokens, API keys, and other credentials are automatically redacted in the UI and API responses.
  </Card>
</CardGroup>

***

## Who Can View the Audit Log

Access is role-based. Two paths grant audit-log read access:

<ParamField path="Base role with audits read permission" type="role">
  Grants visibility into all audit events across the organization. Configured under **Configuration → Roles & Permissions** by enabling the **Audits — read** permission on the role.
</ParamField>

<ParamField path="On-call role with audits read permission" type="role">
  Grants visibility into audit events for on-call resources only — Alerts, Alert Routes, Schedules, Escalation Policies, and related items. Useful when on-call leads need visibility into on-call configuration changes without seeing the full organizational audit history.
</ParamField>

Users without either permission don't see the **Audit Log** sidebar entry under Configuration → Organization.

***

## What Gets Logged

Roughly 60 resource types are instrumented. Highlights:

<CardGroup cols={2}>
  <Card title="Configuration" icon="gear">
    API Keys, Secrets, Roles, On-Call Roles, Memberships, Severities, Environments, Custom Fields, Custom Forms.
  </Card>

  <Card title="Incidents" icon="circle-exclamation">
    Incidents, Action Items, Incident Events, Post-Mortems, Incident Permission Sets.
  </Card>

  <Card title="Workflows" icon="bolt">
    Genius Workflows, Workflow Runs, Workflow Groups — including create, edit, enable/disable.
  </Card>

  <Card title="Integrations" icon="plug">
    Slack, PagerDuty, Opsgenie, Jira, Datadog, GitHub, ServiceNow, Zoom, and every other integration's connection and configuration changes.
  </Card>

  <Card title="On-Call" icon="bell">
    Schedules, Escalation Policies, Alerts, Alert Routes, Alert Routing Rules.
  </Card>

  <Card title="Catalog" icon="folder-tree">
    Services, Functionalities, Groups (Teams), Environments, Causes.
  </Card>
</CardGroup>

Each entry captures:

| Field                     | What It Means                                                                 |
| ------------------------- | ----------------------------------------------------------------------------- |
| `whodunnit`               | User ID of the actor who triggered the change                                 |
| `item_type` and `item_id` | The resource that was modified                                                |
| `event`                   | One of `create`, `update`, `destroy`                                          |
| `source`                  | Where the action came from — `web`, `api`, `mobile`, `slack`, `scim`, `oauth` |
| `api_key_id`              | If the action came from the API, which key triggered it                       |
| `request_id`              | HTTP request ID for tracing through Rootly's logs and external systems        |
| `metadata.ip`             | IP address of the actor, when available                                       |
| `object_changes`          | Before-and-after values for every modified field, with humanized field names  |

<Note>
  **Sign-in and sign-out events are tracked separately** from the main audit log, in Rootly's login activity store. The main audit log focuses on configuration and operational changes, not authentication events. For a unified authentication + audit view, pair the JSON:API export with sign-in events from your IdP (Okta, Azure AD, Google Workspace).
</Note>

***

## View the Audit Log in Rootly

<Steps>
  <Step title="Open The Audit Log">
    In Rootly, go to **Configuration → Organization → Audit Log**. The full event history loads in reverse-chronological order.
  </Step>

  <Step title="Filter By Whatever You're Investigating">
    Use the filter row at the top of the table to narrow down:

    * **Date range** — start and end timestamps
    * **User** — actor who triggered the change
    * **Source** — `web`, `api`, `mobile`, `slack`, `scim`, or `oauth`
    * **Item type** — the resource that changed (e.g., `Incident`, `EscalationPolicy`, `Severity`)
    * **Action** — `create`, `update`, or `destroy`
    * **API key** — if you're tracking the actions of a specific automation
  </Step>

  <Step title="Open A Row To See The Diff">
    Click any audit entry to open the detail drawer. It shows the full before-and-after values for every field that changed, with humanized field names and timezone-aware timestamps.
  </Step>
</Steps>

<Tip>
  **Looking for user permission changes specifically?** Set the **Item type** filter to `Role`, `OnCallRole`, or `Membership` — those three resource types capture role assignments, on-call role changes, and team membership updates respectively. If the affected user is managed via SCIM, also try setting **Source** to `scim` to surface IdP-driven provisioning events; web-UI and API changes appear with `source` set to `web` or `api`. Without an item-type filter, role changes can be hard to spot in a busy audit feed full of incident and workflow events.
</Tip>

***

## Programmatic Access via API

For compliance exports, evidence collection, or building your own audit dashboards, query the audit log through the JSON:API endpoint.

```http theme={null}
GET /api/v1/audits
Authorization: Bearer <your-rootly-api-key>
```

<ParamField path="item_type" type="string">
  Filter to a specific resource type. Examples: `Incident`, `Severity`, `EscalationPolicy`, `ApiKey`.
</ParamField>

<ParamField path="user_id" type="string">
  Filter to actions taken by a specific user.
</ParamField>

<ParamField path="api_key_id" type="string">
  Filter to actions triggered by a specific API key — useful for auditing automations.
</ParamField>

<ParamField path="source" type="enum">
  One of `web`, `api`, `mobile`, `slack`, `scim`, `oauth`.
</ParamField>

<ParamField path="created_at" type="datetime range">
  Supports `gt`, `gte`, `lt`, `lte` operators for time-range queries. Example: `filter[created_at][gte]=2026-01-01T00:00:00Z`.
</ParamField>

<ParamField path="sort" type="string">
  `created_at` for ascending order, `-created_at` for descending. Default is descending (most recent first).
</ParamField>

<ParamField path="page[number] and page[size]" type="pagination">
  JSON:API standard pagination. Maximum page size depends on your plan; iterate through pages for full exports.
</ParamField>

Response includes all the same fields the UI shows (`whodunnit`, `item_type`, `event`, `source`, `object_changes`, etc.) plus the resource's full prior and current state where applicable. Sensitive fields (passwords, tokens, API keys, OAuth secrets) are redacted by the serializer before the response leaves Rootly.

For full API authentication and pagination details, see the [API Reference](/api-reference/overview).

***

## Sensitive Field Redaction

The UI and API responses redact sensitive field values before they leave Rootly. Redaction applies to fields whose names match common credential patterns — `password`, `api_key`, `token`, `secret`, `credentials`, and similar.

What you'll see in place of redacted values:

* Field appears in the diff but the value is replaced with `[REDACTED]`
* The fact that the field changed is still recorded (useful for "rotated the API key on Oct 5")
* The new value is never visible — only that it was modified

This matters for compliance: rotating a secret or updating an integration's API key still generates a complete audit trail, without exposing the new credential to anyone who can read the audit log.

***

## Retention

Rootly retains audit logs indefinitely by default — there's no automatic deletion policy. For long-term compliance archival, use the JSON:API to pull events on a schedule into storage your auditors already own.

***

## Frequently Asked Questions

<AccordionGroup>
  <Accordion title="Do I see sign-in and sign-out events in the audit log?" icon="right-to-bracket">
    No — authentication events are tracked separately from the configuration audit log. For a unified view of auth + audit, pair the JSON:API export with sign-in events from your IdP (Okta, Azure AD, Google Workspace).
  </Accordion>

  <Accordion title="Can I export the audit log as CSV?" icon="download">
    Not directly from the UI. Use the JSON:API endpoint (`GET /api/v1/audits`) to pull the data and convert it to CSV in whatever tool fits your workflow. Most teams pull on a schedule for compliance archival rather than ad-hoc CSV export.
  </Accordion>

  <Accordion title="Are integration secrets visible in the audit log?" icon="file-lines">
    No. Passwords, API keys, OAuth tokens, and other credential-like fields are automatically redacted in the UI and API responses. The audit log records that the field was changed — never the new value.
  </Accordion>

  <Accordion title="Can on-call leads see the full audit log?" icon="phone">
    Only if their role has the **Audits — read** permission on the base role. The on-call role's audit permission scopes visibility to on-call resources only (Alerts, Schedules, Escalation Policies). Grant the base-role audit read permission for full visibility.
  </Accordion>

  <Accordion title="Does the audit log capture incidents and incident actions?" icon="triangle-exclamation">
    Yes. Incidents, action items, post-mortems, incident events, and permission sets all generate audit entries on create, update, and delete. Useful for reconstructing exactly what happened during incident response.
  </Accordion>

  <Accordion title="What happens to the audit log when a user is deactivated?" icon="clock">
    Their historical actions stay in the audit log — the user reference is preserved. Future actions can't be attributed to that user because they no longer have access, but everything they did while active remains traceable.
  </Accordion>
</AccordionGroup>

***

## Next Steps

<CardGroup cols={2}>
  <Card title="API Reference" icon="code" href="/api-reference/overview">
    Authenticate and query the `/api/v1/audits` endpoint for programmatic export.
  </Card>

  <Card title="User Permissions" icon="user-shield" href="/managing-users/user-permissions">
    Grant the **Audits — read** permission to roles that need audit visibility.
  </Card>

  <Card title="Roles" icon="users-gear" href="/managing-teams/incident-roles">
    Configure custom roles with scoped audit permissions for on-call leads, compliance officers, and other audiences.
  </Card>
</CardGroup>