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 Account → Audit Log. Only super admins, admins, and auditors can read it, because it exposes other members’ actions and IP addresses.

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 never logged. Nothing tells you who looked at something, only who changed it. A handful of read endpoints that use POST purely to carry a request body (the dashboard’s batch monitor lookup, the log-parser test preview) are treated as reads and excluded too.
• Unauthenticated requests, including ones whose credentials were rejected.
• SiteQwality 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 the resulting status. That covers validation failures and permission denials alike: a viewer-role user attempting a delete, an API key used outside its scopes, or a write attempted while the account is suspended all appear with their 403. A rejected attempt is worth seeing.

Actor types

Actor type	Meaning
session	A logged-in team member. 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 predate the column and have neither.
impersonated_staff	A SiteQwality staff member acting as one of your users. impersonated_by records which staff member.
system	Reserved. Nothing produces it today.

Reading the log

Each entry carries:

Field	Description
occurred_at	When, in UTC.
actor_type, actor_user_id, actor_api_key_id, actor_api_key_name, actor_m2m_client_id, impersonated_by	Who.
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 is the connection our API gateway actually saw, not a client-supplied header, so it cannot be spoofed by the caller.

action is derived from the path, so it groups related calls without the verb. Some real examples:

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

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

Query it

curl -G https://api.siteqwality.com/account/audit_log \
  -H "Authorization: Bearer $SESSION_JWT" \
  --data-urlencode "action=http.job" \
  --data-urlencode "actor_type=m2m" \
  --data-urlencode "since=2026-07-15T00:00:00Z" \
  --data-urlencode "limit=200"

Super admin, admin, or auditor session required

The endpoint is gated on the super admin, admin, or auditor role, which only a logged-in user session carries. API keys and M2M clients get a 403: a leaked automation credential must not be able to read every member’s actions and IP addresses. Programmatic export for SIEM ingestion is on the roadmap.

Param	Default	Notes
actor_user_id	none	Exact UUID.
actor_api_key_id	none	Exact UUID; narrows to one API key’s actions.
actor_type	none	One of the five above.
action	none	Exact match or dot-prefix: http.job also matches http.job.regions, never http.jobs.
target_kind	none	Exact match.
target_id	none	Exact UUID.
since, until	last 90 days	RFC 3339.
limit	100	Clamped to 1..1000.

Entries come back newest first.

There is no cursor pagination

The only way to reach older entries is to move the since and until window. If a query returns exactly limit rows, assume there are more and narrow the range.

The 90-day read window

Reads are clamped to the last 90 days. A since older than that is silently pulled forward, and omitting since gives you exactly 90 days.

Worth being precise about what that does and does not mean: rows older than 90 days are not deleted. Nothing purges the audit log today. The window is a read limit, not a retention policy, and a longer-term retention story is still an open product decision. If you have a compliance requirement to keep this data beyond 90 days, export what you need on a schedule rather than assuming either that it is gone or that it will stay forever.

Reliability

Audit writes are best-effort. If a write fails, the underlying request still succeeds and the failure is logged internally rather than surfaced to you.

That means the log is an excellent record and not a guaranteed-complete ledger. It is designed so that auditing can never take your account down.

See also

M2M API clients The actor type you will see most from automation.

CSV exports Getting data out for longer-term storage.