Executions and audit

Every call an agent makes through a Gateway becomes an execution: allowed, denied, or waiting for approval. The Executions & audit page lets admins, auditors and approvers look back at each one, step by step, and shows whether the audit trail is intact.

The Executions & audit page#

Open Executions & audit. It shows the executions of the environment chosen in the sidebar, newest first. Each entry shows the tool id, its status, how long ago it happened, and the last error code if there was one. Admins and auditors also see an Audit trail tab: see The audit trail.

Executions appear once the Gateway reports them, usually within seconds. The list loads more as you scroll down, 50 at a time, and its end shows how many executions match. You can also click Load more.

These filters narrow the list:

• Status: Any status, needs settling (unknown outcomes nobody has settled yet), failed or unknown, or one state: pending approval, succeeded, failed, denied, unknown, rejected or expired.
• Agent: when you open the list from an agent on the Dashboard, it shows only that agent's executions. Remove the Agent filter to see every agent's.
• Search: words that must all appear in the tool id, the last error code or the policy rule that decided it, in any case. For example, purchase create.

The states mean:

While the Gateway is sending a call to your system, it shows as Sending.

An execution's timeline#

Click an execution to open its timeline. The header shows the tool id, the agent, the person or customer it acted for, the execution id, its status and the argument fingerprint. The fingerprint is the same one approvers saw on the request, so you can match what ran to what was approved.

If the operation succeeded, the result fields your system returned are shown above the timeline. If it needed approval, the decision is shown with who made it, when, their comment, and the rule and policy version that required it.

The timeline lists each step in order, with its time and who acted. A call that needed approval typically reads:

1. Agent asked; waiting for a person
2. Approval requested
3. Details opened, each time an approver or auditor opened the request
4. Approved, by the approver
5. Gateway received the approval
6. Re-checked and released for execution
7. Sent to the system
8. Completed

An allowed call goes straight to Sent to the system and its result. A refused call shows Denied with its reason, such as policy denied with the rule's id. When the final check refuses an approved call, the timeline shows Re-check refused the execution with the reason, for example tool version changed or expired. When Gatelion cancelled the request because something changed, for example a new policy version, the timeline shows Cancelled: it could no longer run and the panel says why. See Decide approvals.

The timeline doesn't show the argument values. Approvers and auditors of the environment can read them on the request in Approvals.

Unknown outcomes#

Gatelion never retries a write on its own. If the Gateway sent a write to your system and got no usable answer (a timeout, a dropped connection, a server error, a redirect, or a response that was too large), it can't know whether the write happened. Retrying could do it twice, so it marks the execution Unknown: reconcile and the timeline shows Outcome unknown: check the system.

The execution's panel shows a note: "The Gateway can't tell whether this happened in the system, and never sends it again by itself." Find out in the system, then settle the execution in the console:

The execution then shows Settled: it happened or Settled: it didn't happen, with who settled it, when, and the note. Its timeline gets Settled by a person, and the settlement is recorded in the audit trail. An execution can be settled once.

To find what still needs checking, set Status to needs settling: it lists unknown executions that nobody has settled yet.

Reads are different: a read that gets no usable answer fails, because reading twice changes nothing.

Verify the audit chain#

Every request, decision and result is recorded in an append-only audit trail. Each event is chained to the one before it with a hash, per environment, so editing, deleting or reordering an event breaks the chain.

The page header checks the whole chain each time you open the page:

• Audit chain intact · N events: every event links correctly to the one before it.
• Audit chain broken at event N: the chain doesn't hold from that event on. Treat it as an incident and contact Gatelion.

Admins and auditors see this check. Denied calls are part of the trail too, so the trail shows what agents tried, not only what ran.

The audit trail#

Admins and auditors can read the trail itself in the Audit trail tab: every event of the environment, newest first, numbered by its place in the chain. It loads more as you scroll, like the executions list.

Each event shows what happened, when, and who did it: a person, an agent, a Gateway, a customer, or Gatelion itself. Click an event to see its details: the event's name, the execution it belongs to, its hash, and what was recorded with it. Values named like secrets are hidden.

Two filters narrow it:

• By: anyone, or only people, agents, Gateways, customers or Gatelion.
• Search: words that must all appear in the event's name, or in the name or id of whoever did it. For example, approval approved or a colleague's name.

Related#

• Executions and audit explains execution states and the audit chain.
• Decide approvals covers the approval steps in the timeline.
• Error codes lists the codes that appear on executions.

Still stuck? Contact support from the console.