Customer audit log

The audit log answers “who changed this, and when”. Every mutating request made against your account is recorded with the actor, the action, the request path and status, the source IP, and the user agent.

Find it under Settings → Audit log. Only super admins, admins and auditors can read it. Click a row for its full details and links to everything else that actor or target was involved in.

What is and is not recorded

Recorded: every authenticated POST, PUT, PATCH and DELETE against your account, whoever made it and whichever credential they used.

Not recorded:

Reads. GET requests are not logged. The one exception is session replay: every view is recorded as rum.replay.viewed (see who watched). Read endpoints that use POST only to carry a request body (the dashboard’s batch monitor lookup, the log-parser test preview, the consent page loading an AI assistant’s request) are excluded too.
Unauthenticated requests, including ones whose credentials were rejected. Successful, verified incident actions are an exception: responder action links and accepted Slack actions identify the member and incident, so they are recorded.
Site Qwality staff actions, which live in a separate internal audit log. Staff acting as one of your users through impersonation do appear here, marked as such.

A request that identifies its caller and is then denied is recorded with its status, including validation failures and permission denials such as a viewer attempting a delete, an API key used outside its scopes, or a write while the account is suspended.

Actor types

Actor type	Meaning
`session`	A team member using a session or a verified incident action. `actor_user_id` identifies them.
`m2m`	An M2M API client. `actor_m2m_client_id` identifies it.
`api_key`	A static API key. `actor_api_key_id` identifies which one, and `actor_api_key_name` carries its display name. Entries from before 2026-08-06 have neither.
`impersonated_staff`	A Site Qwality staff member acting as one of your users. `impersonated_by` records which staff member.
`connected_app`	An AI assistant (or other OAuth app) acting as the member who approved it. `actor_user_id` and `actor_user_email` identify the member; `connected_app` names the app.
`partner`	A user of your partner account acting on this account.
`system`	Written by Site Qwality itself rather than by a request: the `account.created` entry recorded when the account is set up.

Reading the log

Each entry carries:

Field	Description
`occurred_at`	When, in UTC.
`actor_type`, `actor_user_id`, `actor_user_email`, `actor_api_key_id`, `actor_api_key_name`, `actor_m2m_client_id`, `impersonated_by`	Who. `actor_user_email` is the person behind a session, an AI assistant or a partner action.
`connected_app`	`{ client_id, name }` of the AI assistant involved: the one that acted, or the one connected or disconnected. `name` is what the app registered itself as.
`via`, `mcp_tool`	`via` is `mcp` for the MCP server, `action_link` for a responder action link, or `slack` for an accepted Slack incident action. `mcp_tool` names the MCP tool when applicable.
`consent_granted`, `scopes`	On an `oauth.authorize` entry: whether the member allowed the assistant, and the scopes they granted.
`action`	The path with UUIDs (and free-form segments like RUM release versions) removed, dot-joined.
`target_kind`, `target_id`	The resource type and, when the path had one, its ID.
`http_method`, `http_path`, `http_status`	The raw request and its outcome.
`request_ip`, `user_agent`	Where from. The IP comes from the connection, not a client-supplied header, so the caller cannot spoof it.
`configuration_change`	Optional observed `before` and `after` snapshots for successful policy, on-call schedule and service changes.

action groups related calls without the verb:

Request	`action`
`POST /http/job`	`http.job`
`DELETE /http/job/{id}`	`http.job`
`POST /incident/{id}/acknowledge`	`incident.acknowledge`
`POST /account/m2m_client`	`account.m2m_client`
`POST /oauth/authorize` (a member allowing or refusing an AI assistant)	`oauth.authorize`
`DELETE /account/connected_apps/{id}` (a member disconnecting an AI assistant)	`account.connected_apps`
`GET /rum/{app_id}/sessions/{session_id}/replay` (watching a replay, at most once per viewer per 30 minutes)	`rum.replay.viewed`

The verb lives in http_method, so filter on both when you want “who deleted a monitor” rather than “who touched monitors”.

Configuration comparisons

Open a successful escalation policy, on-call schedule or service change to see Observed configuration: the settings that differ between snapshots taken before and after the request, including child changes such as policy levels and their order, schedule layers and overrides, and service monitor and notification-target links.

The API exposes these snapshots as configuration_change.before and configuration_change.after. Each snapshot has a kind (escalation_policy, on_call_schedule or service) and settings. A creation has a null before; a deletion has a null after. The dashboard CSV export includes both snapshots.

A change to the account’s notification settings records the same comparison, so you can see who turned flap hold or acknowledgment-stops-repeats on or off, and when.

Monitor URLs, notification destinations and credentials are excluded from the snapshots. Snapshots are read separately from the change, so concurrent edits can affect the comparison, and capture is best-effort: an entry can lack a comparison.

Incident actions

A successful responder link writes incident.acknowledge or incident.resolve with via: "action_link", the member and the incident, under the path /incident/action/[redacted]; the action token is never stored. Neither opening the confirmation page nor replaying a used link records a successful action.

An accepted, verified Slack action uses via: "slack". Both record the member with actor_type: "session", and have no request_ip or user_agent.

Outage acknowledgments

Acknowledging a monitor outage is recorded in the audit log, and the acknowledgment also appears in the monitor’s alert history. See Acknowledge a monitor outage.

Filter and export

In Settings → Audit log, narrow the list with Actor type, an Action prefix such as http.job, and a Start (UTC) and End (UTC) range, then click Apply. An entry’s details also have buttons that show every change to the same resource, or every event with the same action.

An action prefix matches exactly or by dot-prefix: http.job also matches http.job.regions, never http.jobs. Entries are newest first and the page loads at most 500; if you see 500, narrow the range to reach older entries. Export CSV saves the loaded entries.

Read it over the API

GET /v1/audit-events returns the same entries for a SIEM or a script, newest first, 50 per page by default (up to 200):

curl "https://api.siteqwality.com/v1/audit-events?action=http.job&limit=200" \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY"

It answers {"data": [...], "next_cursor": "..."}. Send next_cursor back as cursor for older entries; it is null on the last page.
Filters: actor_type, actor_user_id, actor_api_key_id, action (exact or dot-prefix, as above), target_kind, target_id, since and until (RFC 3339). The 90-day window applies.
API keys and API clients need the read:audit scope, which a key with no scope list does not have. Tick Audit log when you create the key or client. Signed-in members need the same roles as in the dashboard. AI assistants are never offered the scope.

AI assistants

An assistant’s changes are logged like any other, and each entry answers three questions:

Who: the member who approved the assistant (actor_user_email). An assistant never acts as anyone else, and never with more than that member’s role allows.
Through which assistant: connected_app.name, for example Claude.
How: via: "mcp" and the tool it used, for example pause_monitor. An API key used through MCP keeps actor_type: api_key and gets the same via and mcp_tool.

Connecting an assistant is logged too: an oauth.authorize entry records who allowed or refused which app, with the scopes granted, and an account.connected_apps DELETE records who disconnected it. To see everything assistants did, set Actor type to AI assistant.

The 90-day read window

The log shows the last 90 days. A start date older than that is pulled forward to the limit.

The window is a read limit, not a retention policy: older rows are not deleted, but no retention beyond 90 days is promised either. If you must keep entries beyond 90 days, save them regularly with Export CSV on the audit log page.

Reliability

Audit writes are best-effort: if a write fails, the request still succeeds, so the log is not a guaranteed-complete ledger. Replay views are the exception: a replay is not served unless its view was recorded.