Audit Log

Every change tracked. Who did what, when, from where, with what details.

What gets logged

Every meaningful change in Signalog produces an audit event. That includes:

  • Authentication events: login, logout, password change, 2FA enable/disable, magic link use, OAuth sign-in
  • Team membership: invites, role changes, removals
  • Project & monitor lifecycle: creation, deletion, configuration changes
  • Incidents: declaration, status transitions, ack, escalation, major incident events
  • Postmortems: creation, AI drafting, publish, unpublish
  • On-call: schedule edits, swaps, override requests
  • Escalation policies: creation, modification, deletion
  • Alert channels: added, modified, deleted, test fires
  • Status page: customization changes, component lifecycle
  • API keys: creation and revocation
  • SSO: config changes, enforcement toggles
  • Billing: plan upgrades and downgrades

Every audit event records:

  • Action: a stable identifier (monitor.deleted, team.member.role_changed)
  • Actor: the user who performed the action (or “system” for automated events)
  • Target: what the action affected (entity ID + a human-readable label)
  • Metadata: action-specific details (old/new values, reason, etc.)
  • IP address: the request’s source IP (honors X-Forwarded-For for proxied deployments)
  • Timestamp: when it happened

Who can read the audit log

Audit log access is admin-only at the team level. Members and viewers can’t see it. This is intentional. Audit logs sometimes contain sensitive metadata (IP addresses, role-change reasons) and should be limited to people who need them for compliance or security investigations.

Accessing the log

  1. Open Team Settings (gear icon next to the team switcher)
  2. Click the Audit log tab
  3. Recent events load with newest first

The default view shows the last 200 events. Use the filters at the top to narrow:

  • Action: filter to a specific action type (e.g., only team.member.role_changed)
  • Actor: filter to events by a specific user
  • Refresh: pull the latest events

For deeper analysis (export to a SIEM, run queries), use the API endpoint:

GET /api/v1/teams/{teamId}/audit?limit=200&action=monitor.deleted

The endpoint requires admin role and an API key with team.audit:read scope.

Use cases

Security investigation

“Did anyone delete a monitor in the last 24 hours?”

Filter: action = monitor.deleted

You’ll see actor, IP, and the monitor that was deleted. If the actor is unexpected, you have a starting point for an incident response.

Compliance reporting

“Show all role changes in the last quarter.”

Filter: action = team.member.role_changed
Date range: last 90 days

Export to CSV via the API. SOC2 auditors love this.

Diagnosing “who broke prod”

“Why did the monitor URL change two hours ago?”

Filter: action = monitor.updated, target = prod-api-monitor

The metadata includes old and new values, so you see exactly what changed and who changed it.

Tracing AI postmortem provenance

“Was this postmortem AI-drafted or human-written?”

Filter: action = postmortem.published

The metadata includes ai_drafted: true|false so you can distinguish human work from AI scaffolding when reviewing publication history.

Retention

Audit events are retained for the same duration as your check-result data retention:

  • Free: 30 days
  • Pro: 1 year
  • Business: 2 years

For longer retention (compliance often requires 7 years), export periodically via the API to your own storage.

What audit logs are NOT

  • Real-time alerting: audit logs are written asynchronously and may lag by a few seconds. For real-time signal use webhooks or web push.
  • A backup: they record changes, not state. You can’t reconstruct a deleted monitor’s full configuration from audit alone (though metadata captures key fields).
  • Deletable: audit events can’t be deleted by users, even admins. This is by design. A tamperable audit log isn’t an audit log.

Performance note

Audit writes are fire-and-forget. They happen in a goroutine after the main action returns. This means:

  • A failed audit write doesn’t fail the original action (we log a warning instead)
  • Audit logs may briefly lag. Querying immediately after an action might miss the latest event
  • Throughput is bounded by Postgres write speed, not the API request path

If you need stronger guarantees (no missed events even on crash), the API exposes a sync version: ?audit_sync=true. Use sparingly. It adds latency to every audited request.

Plan availability

Audit log is available on every plan, but admin-only across the board. There’s no upgrade path to “make it visible to everyone”. That would defeat the purpose.

Next steps