Audit Schema

All Seq audit events carry the following properties.

Property	Description
`@Timestamp` (`@t` in audit files)	The time at which the audit event was generated.
`@MessageTemplate` (`@mt` in audit files)	A human-readable description of the type of event being generated.
`@Exception` (`@x` in audit files)	If the event is associated with an error generated on the Seq server, a full description of the error including a stack trace.
`AuditSession`	A cryptographically random 20-character string uniquely identifying a run of the Seq server application (generated on startup and used until shut-down).
`SequenceNumber`	Within a single `AuditSession`, a sequence identifier beginning at 1 and incremented for every event.
`Principal`	A description of the principal initiating the operation being audited (e.g. a username or API key title).
`PrincipalId`	The Seq identifier for the principal, for example a user id or API key id.
`PrincipalType`	`User`, `ApiKey`, or `Public`.
`OnBehalfOfUserId`	If the principal is acting on behalf of another (for example, an API key with permissions delegated by a user), then the delegating user's id.
`Category`	The category of the audit event, for example `Backup`.
`Operation`	The operation being audited, for example `Download`.
`OperationId`	A GUID identifying the operation. When the operation is audited in begin/end event pairs, all events within the operation carry the same `OperationId`.
`Event`	The kind of event within the operation, for example, `Begin`.

Events that occur during the processing of an HTTP request (i.e. not during background processing) additionally carry:

Property	Description
`HttpRequestMethod`	The HTTP method of the request causing the operation.
`HttpRequestPath`	The HTTP request path (without query string) of the request causing the operation.
`RemoteIPAddress`	The remote IP address from which the request originated, as seen by Seq, or `null` if this cannot be determined.
`XForwardedFor`	The contents of any `X-Forwarded-For` headers, in order, as an array if present, or `null` if no `X-Forwarded-For` headers exist.

The various operations described in Audit Events each carry additional properties describing the operation.

Categories, Operations, and Events

Individual audit events in Seq are described by three identifiers, by convention formatted as Category/Operation/Event.

The category and operation describe the logical operation being audited, for example User/Create, or Backup/Download.

Some operations are audited with a single event, for example, downloading a backup generates a single Backup/Download/Record event.

Other operations are audited in multiple steps. This is generally to ensure that a record of the action is persisted before the operation is completed, and the final result stored in an additional event. Creating a user first generates User/Create/Begin, and then on completion produces User/Create/Complete.

The types of events emitted are:

Event	Description
`Abandon`	Non-blocking record of operation abandonment, for example because of system-implemented validation. Always paired with `Begin`.
`Advise`	Single, non-blocking event that is stored asynchronously and thus is not immediately durable.
`Begin`	Blocking event that is made fully durable before a fallible operation proceeds. May be followed by a `Complete`, `Abandon`, or `Fail` event.
`Complete`	Non-blocking record of operation completion. Always paired with `Begin`.
`Fail`	Non-blocking record of system-level operation failure. Always paired with `Begin`.
`Record`	Single, blocking event that is made fully durable before proceeding.

The Audit Events page documents, for each operation, what the expected events are.

Example audit events

The two events below describe a successful user login. They have been exported from a Seq audit target and reformatted for readability.

`User/LocalLogin/Begin`

{
  "@t": "2023-06-15T03:41:33.0330011Z",
  "@mt": "Beginning login attempt for {Username}",
  "@m": "Beginning login attempt for \"[email protected]\"",
  "@i": "79257acb",
  "AuditSession": "1509KcGAHFRX9v6LZkvQ",
  "Category": "User",
  "Event": "Begin",
  "HttpRequestMethod": "POST",
  "HttpRequestPath": "/api/users/login",
  "OnBehalfOfUserId": null,
  "Operation": "LocalLogin",
  "OperationId": "ef779fbd-8e39-4705-9ecd-b0f9a8ee2266",
  "Principal": "DefaultPublicPrincipal",
  "PrincipalId": "principal-public",
  "PrincipalType": "Public",
  "RemoteIPAddress": "203.0.113.0",
  "SequenceNumber": 13,
  "Username": "[email protected]",
  "XForwardedFor": null
}

`User/LocalLogin/Complete`

{
  "@t": "2023-06-15T03:41:34.0641198Z",
  "@mt": "User {Username} successfully logged in as {UserId}",
  "@m": "User \"[email protected]\" successfully logged in as \"user-16\"",
  "@i": "9bc2134a",
  "AuditSession": "1509KcGAHFRX9v6LZkvQ",
  "Category": "User",
  "Event": "Complete",
  "HttpRequestMethod": "POST",
  "HttpRequestPath": "/api/users/login",
  "OnBehalfOfUserId": "user-admin",
  "Operation": "LocalLogin",
  "OperationId": "ef779fbd-8e39-4705-9ecd-b0f9a8ee2266",
  "Principal": "[email protected]",
  "PrincipalId": "user-16",
  "PrincipalType":"User",
  "RemoteIPAddress":"203.0.113.0",
  "SequenceNumber": 14,
  "UserId": "user-16",
  "Username": "[email protected]",
  "XForwardedFor": null
}

`User/LocalLogin/Abandon`

Had the login attempt been unsuccessful, the completion event would instead have been similar to:

{
  "@t": "2023-06-15T03:41:34.0641198Z",
  "@mt": "The login was rejected",
  "@m": "The login was rejected",
  "@i": "ed56c08c",
  "@x": "Seq.Server.Web.BadRequestException: Invalid username or password.\r\n ...",
  "AuditSession": "1509KcGAHFRX9v6LZkvQ",
  "Category": "User",
  "Event": "Abandon",
  "HttpRequestMethod": "POST",
  "HttpRequestPath": "/api/users/login",
  "OnBehalfOfUserId": null,
  "Operation": "LocalLogin",
  "OperationId": "ef779fbd-8e39-4705-9ecd-b0f9a8ee2266",
  "Principal": "DefaultPublicPrincipal",
  "PrincipalId": "principal-public",
  "PrincipalType": "Public",
  "RemoteIPAddress": "203.0.113.0",
  "SequenceNumber": 14,
  "XForwardedFor": null
}