Decision Logs

Every rule execution is logged with the full request, response, and which conditions matched. Use logs to debug issues, audit decisions, and understand how your rules behave in production.

Logs are retained for up to 90 days on most plans and appear in the dashboard within seconds of execution.

Viewing Logs

Navigate to the Logs tab in the dashboard.

Logs Tab

Each entry shows:

Request and response payloads
Which conditions matched or failed
The materialized vocabulary values used by that rule version
HTTP status, IP address, timestamp, and duration

Filter by rule, status code, or date range to narrow down what you're looking for.

Searching with DDQL

Decision Data Query Language lets you search by the actual data in your requests and responses.

For example, if I wanted to pull rule executions for a particular application_id, I might do the following:

Query Logs with DDQL

Examples

credit_score >= 700 AND approval_decision = "denied"
customer_id = "CUST-12345"
amount > 10000 AND risk_score < 0.2
tier:gold OR tier:platinum

Operators

Operator	Description	Example
`=`	Exact match	`status=approved`
`!=`	Not equals	`status!=rejected`
`:`	Contains (strings) or equals	`name:Smith`
`<` `<=` `>` `>=`	Comparisons	`score>=700`

Combine with AND and OR. Use parentheses for precedence:

(tier = "gold" AND amount > 100) OR tier = "platinum"

Quotes optional unless value contains spaces:

status = approved
city = "New York"

Field names are case-sensitive and must match your schema. Queries search both request and response payloads automatically.

Log Details

Click any entry to see the full request/response JSON, detailed condition evaluation, and timing data.

Rule entries also include Referenced Values. This is the execution-time snapshot of the materialized values used in conditions and function cells, not a fresh lookup, so an older decision remains understandable after a value changes. The panel flags values that differ from their current definition and links to their history. To keep log records bounded, very large individual payloads or exceptionally large reference sets can be marked as partial.

Flow logs also show their correlation IDs (own, root, and invoking flow execution IDs) and a View Execution link that opens a read-only view of the flow as of the version that ran, with the recorded execution path overlaid on the graph. Bulk flow calls record a per-item execution ID for every item in the request array, so each individual run is traceable; the same IDs are returned in the X-Rulebricks-Flow-Execution-Id response header (the call-level ID, for bulk requests) and accepted by the log search.

On private deployments, these visualizations keep working even after the underlying rule or flow is deleted: deletion archives a snapshot, and log links open a read-only archived view labeled with the deletion date.

On private deployments, deleted vocabulary values are archived too. A referenced value remains labeled as deleted in the log detail and its final stored payload remains available for traceback. The public decision-log API exposes the execution snapshot as decision.referenced_values and reports a bounded snapshot with decision.referenced_values_truncated when applicable.

Team Templates Introduction