Skip to main content


The decision log records the policy decisions that OPA makes, regardless which kind of real-world system OPA is integrated with. Each decision log entry records the inputs that OPA was given, the decision that OPA made, a pointer to the policy or data used to make that decision, performance metrics for decision-making, and so on. Each decision log entry is stored in JSON so that it can be applied in a variety of circumstances. You can ask why a decision was made the way it was or how an old decision would be made today using the current policy.

View the Decision Log

To view the decision log in the DAS GUI, in the left navigation panel, under WORKSPACE, click, and then click Decisions tab to view the live decision log. Styra DAS displays all the decisions made across all systems. To view only the decisions for a single DAS system, click on your system name in the left navigation panel and then click on the Decisions tab. Similarly, you can see the decisions for a DAS Stack.

Types of Decision

Every decision log entry is marked as one of the following types:

  • Denied: Decision was to rejected the attempted user action.

  • Allowed: Decision was to accept the attempted user action.

  • Advice: Decision cannot be categorized as either Allowed or Denied. Advice decisions can represent a Mutation.

  • Error: An error like divide-by-zero occurred during policy evaluation.

  • Unknown: Decision cannot be categorized in any other way.


Mutating happens before validating. The resource (as the input) first hits mutating, and if applicable a patch is applied by the mutating rule. Now, the patched resource acts as an input to validating. The decision log for validating (Allowed or Denied) displays the mutated or patched object in the logs.

The Unknown marking appears primarily for a Custom system or policy type when the Styra DAS does not understand the use case and what its decisions represent in the real world. But, the Styra DAS can be configured to understand the decision log format for each of those Custom systems and policy types.

For more details on configuring decision logs, see the decision log configuration page.

Find the Decision

The following tools will help you to find or browse the decision of your interest:

  • Filter: Enter a search term. For example, nginx to restrict the visible entries.

  • Live: Toggle whether to continue updating in (near) real-time.

  • Policy-type: For systems or stacks with multiple policy types (for example, Ingress and Egress), you can choose which ones to view.

  • Outcome: Whether the decision was Denied, Allowed, Advice, Error, or Unknown.

Analyze the Decision

When you find an interesting decision, you can analyze the decision by doing the following operations.

  • Explore the contents of that decision by clicking the arrow on the left-hand side to reveal the full JSON entry. Below are the details for each field in the decision log, but the most important ones are:

    • path: Name of the policy that OPA evaluated.

    • input: The JSON object that OPA made a decision about.

    • result: The decision itself.

  • Replay the decision by clicking the Replay button. Now, Styra DAS will load the decision's input into the current policy and evaluate the results so that you can see what decision your current policy would make. This also makes it easy to change the input to see how the output would change.

  • Copy the decision by clicking on the Context button. This will copy the JSON entry to your clipboard for use elsewhere.

  • Copy a link to the decision by clicking on the Context button. This gives you a link that makes it easy to share exactly that decision with other people.

Decision Log Entry Fields

The following shows the list of individual fields for each decision log entry in the order of importance:

  • path: The name of the policy that OPA evaluated (policies in OPA are arranged hierarchically).

  • input: The full input OPA used to make a decision (For example, Kubernetes expects an AdmissionReview request.

  • result: The result of policy evaluation (For example, Kubernetes expects an AdmissionReview response.

  • allowed: A boolean indicating whether the response was allowed or denied.

  • reason: A statement explaining why the decision was made.

  • error: The error object returned to the user if policy evaluation failed.

  • revision: An identifier for the version of the policy (and all of its dependencies) used to make the decision.

  • metrics: The metrics OPA recorded when making the decision. For example, the following shows the list of metrics:

    • timer_rego_module_parse_ns: Time (in nanoseconds) to read the policy into memory.

    • timer_rego_module_compile_ns: Time (in nanoseconds) to prepare the policy for evaluation.

    • timer_rego_query_parse_ns: Time (in nanoseconds) to read the query into memory.

    • timer_rego_query_compile_ns: Time (in nanoseconds) to prepare the query for evaluation.

    • timer_rego_query_eval_ns: Time to evaluate the query.

    • timer_server_handler_ns: Total time from when OPA received the query to the time it responded.

  • labels: The labels that OPA was configured with.

  • requested_by: The IP address and port of the service that requested a policy evaluation.

  • decision_id: A unique identifier generated by OPA.

  • agent_id: A unique identifier of the OPA instance responsible for the decision.

  • timestamp: Timestamp of the decision (OPA-side clock).

  • received: Timestamp when the decision log batch was received by Styra (server-side clock).

  • system_id: A unique identifier of the system.

  • columns: A list of user-defined column values reflecting values extracted from the decision result, input or other fields.

Retention Policy

The decision log retention defaults are 336 hours (14 days) archiving of received OPA decision batches and then a smaller window of 72 hours (3 days) for the Elasticsearch to hold the latest decisions for search purposes.