Audit logs

To give you visibility over the changes that are made within your incident.io account, we use an audit log. Our audit log is powered by WorkOS. The log is available for customers on our Enterprise plan.

The audit log contains information about any configuration changes, as well as changes to a user's permissions (e.g. being given a new role, or access to a private incident).

Each entry will have an actor (the person or system that made the change) and one or more targets (a thing that was modified by this change). It will also include the Location and User Agent of the actor, where applicable.

Each entry will conform to a schema, which is documented here. Each entry also has a version, so that if our schema changes over time you’ll still be able to parse old events.

We’ll retain these entries for one year.

Audit log entries start from 18 April, 2023 (there are no entries available from before that date) and are retained in WorkOS for 365 days.

You can view your audit log via our security settings page.

From there, you'll be able to:

• View the entries via a web interface (filterable by target, event type, actor and date)
• Export the entries for a given time period to a CSV
• Set up a log stream to a provider of your choice (e.g. Splunk or an Amazon S3 bucket)

Each entry will have an actor associated with it, which is one of 6 types:

Users

This is for changes triggered by the actions of a particular user in your account.

As an example:

"actor": {
    "type": "user",
    "id": "01G0J1EXE7AXZ2C93K61WBPYEH",
    "name": "Kelsey Mills",
    "metadata": {
      "user_base_role_slug": "admin",
      "user_custom_role_slugs": "engineering,security"
    }
  }

API Keys

This is for changes triggered by an API key.

As an example:

"actor": {
    "type": "api_key",
    "id": "01G0J1EXE7AXZ2C93K61WBPYEH",
    "name": "Lisa's development key",
    "metadata": {
      "api_key_roles": "incident_creator,global_access"
    }
  }

Integrations

This is for changes triggered by a system. Sometimes that will be a third party system (e.g. a user might be created via Slack) or sometimes it might be something triggered from inside incident.io (e.g. a severity created as part of setup).

As an example:

"actor": {
    "type": "system",
    "id": "incident_setup",
    "name": "incident.io (setup)",
    "metadata": {}
  }

Workflows

This is for changes triggered by a workflow: for example, a workflow that invites users to a private incident.

As an example:

"actor": {
    "type": "workflow",
    "id": "01G0J1EXE7AXZ2C93K61WBPYEH",
    "name": "Auto-invite security team to private incidents",
    "metadata": {}
  }

External resources

This is for changes triggered by a specific external resource (also known as an attachment).

As an example:

"actor": {
    "type": "external_resource",
    "id": "01G0J1EXE7AXZ2C93K61WBPYEH",
    "name": "#1234 Increased API latency",
    "metadata": {
      "external_resource_type": "pager_duty_incident",
      "external_resource_external_id": "q1234"
    }
  }

Alerts

This is for changes triggered by a specific alert (e.g. from Datadog or Grafana).

As an example:

"actor": {
    "type": "alert",
    "id": "01G0J1EXE7AXZ2C93K61WBPYEH",
    "name": "Staging: pod CPU high",
    "metadata": {
      "alert_source_id": "01HB0ZG3B0HM04RCXNSPV1EDYG"
    }
  }