Skip to main content
An execution journey answers a different question from Activity, database audit, and logs: it follows the technical path of one operation across service boundaries. Use it when you need to know where a request spent time, where it failed, or whether asynchronous work was accepted versus completed. Open Security Admin → Observability → Executions. Operation and Execution references from Jobs, Assistant messages, audit records, logs and dashboards open the shared execution dialog without leaving the current page or changing its URL. Press Escape or click outside to return to the caller. Existing Trace URLs redirect to Observability Executions.

​
Start with the right identifier

For HTTP endpoint support, capture the UTC timestamp, method/path, response status, and x-revo-oid response header. Do not collect the bearer credential or any signed URL.

​
Investigation sequence

An accepted asynchronous request only establishes that work was queued or started. Confirm a terminal Job/run state, delivery result, or finalized Storage artifact before concluding that work succeeded.

​
Resolve dates before loading logs

An exact identifier is independent of the list’s default 24-hour period. Native retained evidence resolves execution dates across up to 90 days; a Job created days before it starts uses its persisted execution timestamps. Missing or long execution windows are disclosed as partial coverage. A source without the native index needs an explicit UTC window. Choose Logs for this operation to inspect bounded log evidence after selecting the journey. Open payloads only for the entries needed to answer the question. Historical summary recovery can provide a journey or usage aggregate without detailed messages; absence of those messages does not prove that an event never happened.

​
What to look for

  • Ingress and authorization: did the request reach the intended active Endpoint under an authorized principal?
  • Route and validation: was a definition selected and did its guard reject the structured input before execution?
  • Resolution: which Component version, custom runtime revision, schema Component, library set, and execution policy were selected?
  • Execution: which segment is slow or failed; did the configured timeout or cancellation boundary apply?
  • Async handoff: is a queue acceptance followed by a durable processor/Agent/automation result?
  • External work: did application code record a safe provider correlation ID that lets you verify an ambiguous timeout without replaying it?

​
Trace, logs, and history together

​
Safe support bundle

Provide a narrow time range, IDs, sanitized status/error text, resource name/ID, selected version, and reproducible non-secret input shape. Redact headers, cookies, API keys, Secret values, private prompts, Storage download URLs, and customer payloads unless an approved secure support channel specifically requires them.
Use the Observability guide for the complete operator workflow, then return here when the investigation needs a execution-first view.
Last modified on October 5, 2026