Audit and activity issues

Identify the request you are looking for

Begin with the person, workspace, connection, tool, and approximate request time. Personal activity is scoped to the signed-in account, while the Admin workspace is for administrators reviewing organization activity. A security role alone does not grant the Admin workspace.

Separate a client connection problem from a request execution problem. A call that never reached Durin’s authenticated request path may not have the tool activity record you expect. Preserve any client error and request identifier so the two sides can be compared.

Requests not appearing in audit log

If requests seem to be working but are not appearing in the audit trail:

1. Check the time range filter — the default view may not include recent requests.
2. Verify you are looking in the right workspace (personal shows your activity, admin shows organization activity).
3. Confirm the request actually reached Durin — check your MCP client logs for transport errors.
4. Wait a moment — audit entries may have a short processing delay.

Understanding uncertain outcomes

An uncertain outcome means Durin dispatched the request to the upstream provider but could not confirm whether it succeeded or failed. This can happen with network timeouts or provider errors. Durin records the uncertainty rather than guessing — check the upstream system directly to verify the actual outcome.

Performance questions

The Performance page shows request latency and throughput metrics. If requests feel slow, check whether the latency is in Durin's policy evaluation (typically fast) or in the upstream provider response time (shown separately in the performance breakdown).

Read decision and outcome together

A record can show an allowed decision with a failed execution outcome because the provider failed after authorization. An approval-required decision means the original request returned without executing. A later exact retry is a separate point in the workflow that also needs inspection.

Use the tool, resource, argument digest, versions, and timestamps to follow the relevant request. Do not interpret an approval event as an upstream success or interpret the existence of an activity row as proof that company data was changed.

Check whether latency is in Durin or upstream

Use Performance to compare the displayed Durin and upstream timing for the affected requests. Compare similar tools and periods rather than treating one slow response as a general gateway slowdown.

1. Choose the time range that contains the reported request.
2. Identify the affected connection or tool and inspect the available timing breakdown.
3. Check whether delays are concentrated in upstream responses or the Durin portion of the request.
4. Compare the timing with errors or uncertain outcomes and the provider’s observed state.

Prepare a useful audit investigation

Collect the request or execution identifier, timestamp, identity, connection, tool, decision reason, and outcome available in the interface. Add relevant approval references and version information for an approval flow.

Metadata-only retention is the default, so do not expect every audit record to contain the original arguments or full response. Review any configured payload capture and retention separately. Preserve the available metadata without copying provider secrets or sensitive payloads into an unrelated support channel.