Executions & Observability

Observability in Confluye covers run logs, per-execution detail, aggregate statistics, and audit trails — everything you need to see what ran, what it produced, and who changed what.

Run logs

Workflows → Active deployments lists Production and named previews with their deployed version, on/off state and pending executions. Use its switch to stop a destination, or open it to inspect and manage its deployment. An off destination with runs still being canceled shows Stopping. A destination whose current authority or connections are unavailable shows Blocked.

The destination panel reports recorded compute credits, including segment-linked adjustments, and managed AI provider cost in USD for the current UTC calendar month. These totals come from retained billing records, not the run's estimated cost. They can update after active work finishes. Provider charges made through your own credentials are not managed AI charges. Costs without enough retained destination information are not assigned to a preview; older workflow-attributed usage maps to Production. Workflow run counts cover retained executions and can have a different time range from the monthly billing totals.

The Executions view lists every workflow run in the workspace. Each run carries its status, trigger, duration, cost, and per-node steps. You can filter by:

• Status — queued, running, waiting, succeeded, failed, canceled. waiting is a real, filterable status for runs paused on a durable Wait or approval.
• Trigger — manual, webhook, schedule, copilot, api.
• Workflow and time range — 1h, 24h, 7d, 30d, or all time.
• Free-text search across run id, workflow name, status, trigger, error, input/output, step outputs, and log messages.

Results sort by newest, oldest, duration, cost, workflow, or status.

Ask about runs from chat

The Command Center chat answers run-history questions with real data: name the workflow and, if you want, a status ("¿Por qué falló la última ejecución de Resumen diario?", "which runs of Weekly digest succeeded?"). The answer lists the matching runs with status, time, duration, and the last error or log line, cites each run, and offers Open Logs to continue in this view.

Execution details

Open a run to see its per-step timeline. Each step exposes its node id, node type, label, status, duration, error, and output. The node execution inspector shows the input, output, request, and response for an individual node.

Inspecting large runs through MCP

External agents can inspect large executions through MCP runs.get without fetching every input and output. The default response contains metadata and paginated node states, errors, and logs; nodeId selects one node. Optional payload windows let the agent retrieve larger redacted data in parts. See MCP run inspection for paging parameters and examples.

The GitHub PR Code Review template accepts pull requests that are opened, reopened, updated with commits, or marked Ready for review (ready_for_review). The review checks current GitHub metadata before publishing; a draft, closed, or merged PR cannot receive findings. Other actions, including converting back to draft and editing the description, are ignored. A run can succeed with a final result of ignored; that means no review was published.

Existing workflows keep their deployed version when a template changes. If marking a PR ready still produces ignored, add ready_for_review to the event validator's action list (if configured) and to Route valid event, connect that route to Fetch current PR metadata, then publish the corrected version through the workflow's required approvals. Keep repository restrictions and the draft/current-commit checks in place.

Verify the Active version after publication, not only the candidate shown in the editor. If deployment reports approved_manifest_missing, finish the corrected version's change request in Approvals and use Approve and enable (or Enable approved version after approval). Until activation succeeds, incoming GitHub events continue to use the previous deployed graph. Then redeliver the ready_for_review event in GitHub and inspect its new execution: it must use the corrected active version, select the ready_for_review route, and publish a review for the current commit. A green succeeded execution with ignored or stale is not proof of publication.

For this workflow, an omitted GitHub patch is recovered from the complete diff or the exact merge-base and reviewed-commit files. Reconstructed patches are verified against those files; equivalent diff algorithms may count changed lines differently. Local reconstruction has a ten-second per-file budget. If complete context remains unavailable, the review stops without publishing partial findings. Reconstructed lines are not used for GitHub inline comments.

Statistics

The executions dashboard summarizes activity: total, succeeded, and failed runs, success rate, average and p95 duration, total cost, active runs, and breakdowns by status and trigger. It also surfaces the slowest recent runs and the most recent failures. Logs can be exported for offline analysis.

Audit logs

A separate Audit Logs view records who did what across the workspace — API-key creation and revocation, workflow deploys and promotions, schedule and credential changes, and more. Each event has an actor (user, apiKey, or system), a resource type, an action, a severity (info, warning, critical), and a message. Audit events are also available via GET /api/v1/audit-logs.

Sentry and Telegram alerts

Sentry is additive to the canonical Confluye run history. Browser, server, and worker failures can share one release and safe trace/run identifiers, while request bodies, prompts, cookies, credentials, and arbitrary headers remain excluded. When configured beside OpenTelemetry, both exporters use the same Node tracing provider.

The Sentry issue to Telegram alert template accepts signed new and regression transitions, suppresses duplicates, and queues a durable plain-text Telegram delivery. The run detail exposes the transition fingerprint and delivery ID, never the hook secret, route token, bot token, chat binding, incident payload, or final message.

Operators should investigate from the Confluye run first. Failed Telegram deliveries expose bounded status, attempts, ambiguity, and correlation fields through the authenticated notification-delivery API. Admins and Owners may replay a retained failed delivery; replay is audited and can duplicate a message after an ambiguous provider timeout.

Retention

Two environment variables control how long observability data is kept:

Both are clamped to 1–3650 days.

Next steps