Unified Observability workspace
Open Security Admin → Observability with instance-administrator access. The workspace has Overview, Executions, Logs and Agents tabs. Overview, including its performance analysis, shares a UTC time window and investigation context with Executions and Logs. Agents uses its own diagnostic scope. Browsing defaults to the last 24 hours, and population statistics cover up to seven days. Exact Operation, Execution, Job, Event and Schedule identifiers use the native retained correlation index independently of the browsing period, then resolve the dates of the selected execution. Identified journeys can inspect up to 90 days of retained evidence through bounded continuation pages. Sources without that index require an explicit date window; an empty recent search does not establish that an older execution is absent. Use Operation ID to find related execution roots, then select a result to inspect its recorded journey. Component, Endpoint, Job, Event, Schedule and Storage references open the corresponding accessible resource by its confirmed identifier. Names and filenames are display labels. A group without a valid resource identifier remains available for execution inspection. Lists retain successful reads, filters and selection while switching workspaces. Refresh advances the selected time snapshot while keeping the previous results and selection visible until the new read completes. Repeated refreshes are disabled while the current refresh is running. An expired investigation is retried once with a fresh context; permission and query-limit errors remain explicit. Overview Performance sorts and filters the loaded resource aggregates in the browser. Load remaining statistics before comparing the complete population; an incomplete duration population is labelled rather than treated as complete. The journey distinguishes recorded parents, missing or ambiguous edges, retry relationships and absent terminal events. A Job’s creation-to-start waiting interval is shown separately when both timestamps exist. A missing correlation in historical logs cannot establish causality. Logs includes all retained visible rows in the window, including application messages without an execution origin. Select a row to load its retained payload. Full payloads load on demand throughout the retained 90-day window, including older entries whose background import retained only metadata. If the original payload has expired or is absent, its metadata remains visible. Native Job, Event and Schedule history links appear only for confirmed records; repeated clicks reuse the same resource panel. Review the selected execution’s coverage notes alongside its journey. Older records may be unavailable, details may be redacted or truncated, and some parents may be outside the selected window or inaccessible. Refresh to include newly retained evidence; an incomplete journey is not proof that the omitted step never happened. Diagnostic reads allow large log partitions: deployment defaults are 256 GiB per query and 4 TiB per investigation, with a 45-second query deadline. Administrators can configure higher scan allowances at deployment. These are scan ceilings; completed reads account for their actual provider billing. Time, tenant, visibility and concurrent-read controls still apply.Start with the question
Correlation identifiers
Collect identifiers before opening a support case:
The structured log field historically named
jobId may carry an Endpoint Execution ID. In operator-facing workflows, interpret it as Execution ID unless you are viewing a durable Job record.
Activity and version history
Activity is snapshot-backed resource history. It supports:- resource-type inclusion and exclusion;
- exact resource and creator filters;
- term search;
- absolute or relative time windows;
- cursor pagination;
- sanitized top-level diffs;
- loading one full accessible historical version.
Activity is resource change evidence. It does not replace execution Trace or business-specific audit history such as Database row audit.
Logs
Open Security Admin → Observability → Logs for instance-wide structured logs. Filter early by time and identifiers, then narrow by service, severity, event name, account, or execution context. For searchable fields, the Advanced filter workspace, and practical HTTP, MCP, and execution examples, see Search instance logs. Good diagnostic filters are:- a tight UTC time range;
- Operation ID or Execution ID;
- the Endpoint, Component, Job, Agent, or account identifier;
- warning and error severity;
- one lifecycle or event name.
Trace
Open Security Admin → Observability → Executions to follow an operation across service boundaries. Clickable Operation and Execution references in Jobs, Assistant messages, audit records, logs and dashboards open the shared execution dialog while preserving the current page and URL. Press Escape or click outside to dismiss it. Reopened panels reuse recent successful reads; Refresh requests fresh evidence. Existing Trace URLs redirect to Observability Executions. Execution journeys are most useful for:- matching ingress to downstream execution;
- locating the slow or failing segment;
- separating an authorization failure from a runtime failure;
- distinguishing queue acceptance from actual processing;
- correlating a webhook, event, job, or Agent dispatch.
Endpoint statistics
Endpoint statistics summarize invocation volume and execution outcomes. Use them to locate a regression or traffic change, then open a representative execution rather than drawing a root-cause conclusion from an aggregate alone. The statistics surface is cached briefly, so it is optimized for operational trends rather than an exact per-second ledger.Recognize AI-initiated work
The Logs grid includes AI activity immediately before Message. True means that verified evidence connects the action to a RevoEngine AI invocation, including work queued by that invocation and executed later. Unknown means that no such evidence is retained; it does not identify the action as human work. Filter AI activity to True to inspect proven AI-originated actions, or use the empty-value filter for unknown records. AI mode, Assistant thread ID and Execution user ID are additional filterable columns. Log details and the execution inspector show these identifiers when available, connecting the action to its conversation and the account used for execution. Executions and trace navigation retain the execution actor’s avatar or service-account icon with a white AI sparkles icon on a black badge. Interactive AI identifies Assistant tool dispatch; Autonomous agent identifies autonomous Agent dispatch. The mode is recorded during execution and retained across queued work. Verified AI evidence without a recorded mode shows AI activity. This provenance does not grant permissions. Automations still execute under their configured account, with current account status and permissions checked at execution. Disabling that service account or revoking a required role prevents the action even when its AI provenance is valid.Job and event evidence
For background work, use this order:File origin and upload timing
Use a Storage entry ID or upload session ID in the Observability search and select the Storage identifier type. Choose the UTC window containing the upload or replacement, then open the recorded journey. Accessible Storage references open the file. To locate a file by name first, use the Storage Explorer, then investigate its entry ID. Upload sessions and native Storage writes record their creating execution as a parent. This also connects a managed direct upload to the original operation when finalization arrives in a later request. SFTP and HTTP imports retain their recorded source classification. Upload lifecycle logs distinguish reservation, finalization, failure, cancellation, expiry and replacement. An upload session’s duration runs from reservation to its terminal state: it includes producer waiting, byte transfer and finalization. Native write timing covers preparation, writing and the committed file entry. These durations do not measure network transfer alone. Follow the recorded child Event or Job to assess later processing separately. Replacement gives the current file version its own write origin. Later metadata edits, reads or deletion retain the execution that performed that action. Historical files without a recorded origin remain uncorrelated; matching a name or timestamp does not prove their source.Database audit
Database row audit is a separate domain-specific ledger for Tables with audit enabled. It records insert, update, and delete snapshots from the enablement point onward, together with actor, row, operation, and time. Use the cross-Table Databases → Audit grid for investigation and the Table-specific audit route for one data source. Open one audit event to load complete before/after detail.Instance Usage
Open Settings → Usage for AI, Transfer, Storage, Database, Jobs, Endpoints and Webhooks. The view combines current capacity with measured consumption and period comparisons. Inventory counters also cover accounts, groups, API keys, Components and automation definitions. Legacy Files APIs remain available; native Storage uses physical inventory and observed transfer. One UTC period applies to charts and drill-downs. The lower bound is inclusive, the upper bound exclusive; no range selects the current UTC month through now. Select resources, accounts or executions to inspect recorded consumption. Compact execution details have a minimum 90-day retention. Older resource summaries use whole UTC days and return their effective bounds; unavailable account/execution history is shown explicitly. Elapsed execution time is not CPU time, and Webhook delivery duration is unavailable. Transfer records deduplicate repeated exports, including historical terminal logs without provider insert IDs. External, internal and unclassified native Storage traffic remain distinct. Incomplete provider coverage is disclosed, and unclassified traffic is excluded from the external transfer threshold. Monthly thresholds use a UTC calendar month and are soft: exceeding them does not itself reject uploads or executions. This surface does not calculate prices or collect payment. The administrator APIs areGET /api/v1/config/instance/usage and GET /api/v1/config/instance/usage/executions. AI analytics continue to use retained model-call evidence. Usage and Observability answer different questions: measured consumption versus recorded execution evidence. See Limits and quotas for configuration semantics.
Historical coverage
Historical recovery can restore execution summaries and recorded consumption without restoring every detailed log payload. Recovered summaries remain labelled as partial evidence; missing messages, diagnostic fields and lineage are not reconstructed. Import progress and retained source coverage determine which dates are available. Ninety-day retention is a retention boundary, not a promise that data predating collection has already been recovered. Current capacity charts cannot be reconstructed from execution logs alone.Sensitive data
Operational evidence is sanitized at platform boundaries, but application-authored logs can still expose data if you log it yourself. When reporting a problem, share IDs, timestamps, sanitized status/error text, and reproduction steps. Replace tokens with variable names such as$REVO_API_KEY.
A practical investigation
When an asynchronous integration appears stuck:- Capture UTC time, Job ID, and the initiating Event or Schedule ID.
- Check whether the Job is pending, processing, terminal, or part of a retry chain.
- Confirm the execution principal is active and still has required roles and ACL access.
- Inspect job logs for the first application error.
- Follow the Operation ID in Trace if dispatch or an external call is unclear.
- Inspect Event History to distinguish a filtered target from a failed execution.
- Verify any expected Storage artifact is finalized.
- Retry only after deciding whether previous external side effects may have completed.
Production checklist
- Emit compact structured application logs.
- Pass stable business correlation IDs through integrations.
- Capture Operation ID, Execution ID, and durable object IDs.
- Separate accepted, processing, and terminal states in your UI.
- Set retention appropriate to your compliance needs.
- Alert on terminal failures and retry exhaustion, not transient queue states alone.
- Review Usage trends by UTC period and by execution principal.
- Redact evidence before sharing it outside the instance.
Related guides
Endpoints
Operate synchronous application APIs.
Automation
Understand Job, Event, Schedule, and Webhook evidence.
Databases
Enable and investigate row-level audit history.
AI and Agents
Inspect Assistant threads, Agent runs, approvals, and tool activity.