Skip to main content

​
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.

Full Change History

Every create, update, and delete across configuration, integrations, incidents, workflows, and on-call settings. Captures before-and-after field values.

Filter And Drill Down

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.

API And Webhook Access

JSON:API endpoint for programmatic export. Optional outgoing webhook streams every audit event to your SIEM in real time.

Sensitive Field Redaction

Passwords, tokens, API keys, and other credentials are automatically redacted in the UI, API responses, and webhook payloads.

​
Who Can View the Audit Log

Access is role-based. Two paths grant audit-log read access:
​
Base role with audits read permission
role
Grants visibility into all audit events across the organization. Configured under Configuration → Roles & Permissions by enabling the Audits — read permission on the role.
​
On-call role with audits read permission
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.
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:

Configuration

API Keys, Secrets, Roles, On-Call Roles, Memberships, Severities, Environments, Custom Fields, Custom Forms.

Incidents

Incidents, Action Items, Incident Events, Post-Mortems, Incident Permission Sets.

Workflows

Genius Workflows, Workflow Runs, Workflow Groups — including create, edit, enable/disable.

Integrations

Slack, PagerDuty, Opsgenie, Jira, Datadog, GitHub, ServiceNow, Zoom, and every other integration’s connection and configuration changes.

On-Call

Schedules, Escalation Policies, Alerts, Alert Routes, Alert Routing Rules.

Catalog

Services, Functionalities, Groups (Teams), Environments, Causes.
Each entry captures:
FieldWhat It Means
whodunnitUser ID of the actor who triggered the change
item_type and item_idThe resource that was modified
eventOne of create, update, destroy
sourceWhere the action came from — web, api, mobile, slack, scim, oauth
api_key_idIf the action came from the API, which key triggered it
request_idHTTP request ID for tracing through Rootly’s logs and external systems
metadata.ipIP address of the actor, when available
object_changesBefore-and-after values for every modified field, with humanized field names
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. If you need a unified authentication + audit feed, route both through your SIEM via the webhook stream covered below.

​
View the Audit Log in Rootly

1

Open The Audit Log

In Rootly, go to Configuration → Organization → Audit Log. The full event history loads in reverse-chronological order.
2

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
3

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.

​
Programmatic Access via API

For compliance exports, evidence collection, or building your own audit dashboards, query the audit log through the JSON:API endpoint. 
GET /api/v1/audits
Authorization: Bearer <your-rootly-api-key>
​
item_type
string
Filter to a specific resource type. Examples: Incident, Severity, EscalationPolicy, ApiKey.
​
user_id
string
Filter to actions taken by a specific user.
​
api_key_id
string
Filter to actions triggered by a specific API key — useful for auditing automations.
​
source
enum
One of web, api, mobile, slack, scim, oauth.
​
created_at
datetime range
Supports gt, gte, lt, lte operators for time-range queries. Example: filter[created_at][gte]=2026-01-01T00:00:00Z.
​
sort
string
created_at for ascending order, -created_at for descending. Default is descending (most recent first).
​
page[number] and page[size]
pagination
JSON:API standard pagination. Maximum page size depends on your plan; iterate through pages for full exports.
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.

​
Stream to a SIEM

For SOC2/ISO27001 compliance, most teams stream Rootly’s audit events into a long-term SIEM (Datadog, Splunk, Sumo Logic, or similar) so the evidence sits inside their existing compliance archive. Rootly supports this via an outgoing webhook.
The audit-log webhook is gated by a Flipper flag (enable_audit_log_webhooks) — contact support@rootly.com to enable it for your organization. Once enabled, every audit event fires the webhook in real time.
1

Request The Webhook

Email support@rootly.com to enable audit-log webhooks for your org.
2

Configure An Outgoing Webhook

Once enabled, configure a new outgoing webhook in Configuration → Webhooks subscribed to the audit_log.created event. Set the destination URL to your SIEM’s ingestion endpoint and add any auth headers your SIEM requires.
3

Validate The Stream

Trigger a small configuration change in Rootly — rename a severity, toggle a workflow. Within seconds, the audit event should arrive at your SIEM with the full payload. Confirm the redaction is happening as expected (no secrets in the body).
See Outgoing Webhooks for the full webhook configuration reference.

​
Sensitive Field Redaction

Both the UI/API responses and the webhook stream 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, stream to your SIEM via the webhook so the evidence lives in your own retention-controlled storage as well.

​
Frequently Asked Questions

No — authentication events are tracked separately from the configuration audit log. To get a unified view of auth + audit, stream the audit-log webhook to your SIEM and pair it with sign-in events from your IdP (Okta, Azure AD, Google Workspace).
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.
No. Passwords, API keys, OAuth tokens, and other credential-like fields are automatically redacted in the UI, API, and webhook stream. The audit log records that the field was changed — never the new value.
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.
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.
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.

​
Next Steps

Outgoing Webhooks

Configure the audit-log webhook stream to your SIEM. Required for SOC2/ISO27001 long-term archival.

API Reference

Authenticate and query the /api/v1/audits endpoint for programmatic export.

User Permissions

Grant the Audits — read permission to roles that need audit visibility.

Roles

Configure custom roles with scoped audit permissions for on-call leads, compliance officers, and other audiences.