Skip to content

The Query Log gives record-level detail on individual queries captured by Database Activity Monitoring — who ran a query, when, from what IP address, and what policy decisions applied. This is distinct from System Audit Log, which records platform-administrative actions, not query activity. Query audit records appear once capture is set up — through the Snowflake Integration Overview, the Sidecar Integration Overview, or Security Intelligence Scout.

Each query audit record contains actor information (username, role, IP address), account identifiers, query metadata (timestamp, query type), and result information (row count and the policy decisions applied to the query). Snowflake and OLTP records also carry source-specific fields, such as the warehouse (Snowflake) or the repository user (OLTP).

ALTR redacts sensitive values from query text, so that data queried against your sources doesn’t persist in the audit trail.

  • String literals are replaced with 'literal_string'.
  • Integer values are replaced with random digits of the same length — age > 25 is stored as age > 38.

Redaction is always applied and cannot be disabled.

To view the Query Log:

  1. Select Query Log in the navigation menu.
  2. Select Cloud Integrations to view Snowflake query records, or select Sidecars to view OLTP query records.
  3. Expand a log entry to see its full detail, including a view of the raw JSON record, which holds the complete set of fields for the query.

Copy the full query text or the query ID when you need to locate a query in its source system or reference it with ALTR Support. For Snowflake records, this is the Snowflake query ID. For OLTP records, ALTR generates its own per-query identifier, distinct from the database’s own query ID.

To copy the query ID or query text:

  1. Select Query Log in the navigation menu.
  2. Locate the query log entry.
  3. Click Query Text or Query ID. ALTR displays the full value in a modal.
  4. Click Copy. The button label changes to Copied.

To filter the Query Log:

  1. Click Filter on the Query Log.
  2. Set the filter values to narrow entries down — searches can be filtered by time range, integration type (Snowflake, OLTP, or all), username or role, IP address, query type, and data source or tag.

Filters are combined with AND logic only — there is no OR or NOT operator.

On Snowflake, the same records also feed Policy Alerts, ALTR’s legacy access-rate and time-window alerting. Only OLTP records feed Audit Reports. Query Log data can be exported to a customer-owned Amazon S3 bucket through Amazon S3 Integration.

Snowflake query audit records include Snowflake-specific fields such as the warehouse and account identifier. User identity is the Snowflake username. A Snowflake record’s policy decision is recorded at query time or at audit time — when the audit record is processed — and the recorded decision can differ between the two. Records generated from a tag-based masking policy don’t indicate which specific columns were accessed; instead, they carry the tag information — the tag key and value — from the policy that produced them. See Snowflake Integration Overview for how Snowflake capture works.

OLTP query audit records identify both the repository user (the database credential) and the consuming user (the identity from your identity provider); these can differ when applications use shared service accounts. Records captured by the sidecar also carry a qualified path for column references — a per-column set of object name and type segments locating where the column lives — on projected columns, scanned columns, and destinations. Engine-specific fields include the client hostname for SQL Server and the application name plus a connection UUID for MySQL. OLTP query audit records can also include activity captured by Security Intelligence Scout. See Sidecar Integration Overview for how OLTP capture works.