Skip to main content
This guide is for teams who have Agents running in production and need to answer operational questions through the public API: Is this Run healthy? Did it complete? Where did it fail? Why is the failure rate rising? It covers patterns for checking Run status, diagnosing failures, building aggregated views, and integrating Duvo data into your existing observability tools. Where the API has gaps, each section notes the current limitation and the recommended workaround. All endpoints are on the base URL https://api.duvo.ai/v2; see Running Agents via API for authentication and the error model.

Checking Whether a Run Is Healthy

Poll a single Run until it finishes

Runs are asynchronous. Start a Run, capture the run_id from the response, then poll GET /runs/{run_id} until the status reaches a terminal state. Terminal statuses: completed, failed, stopped, interrupted Non-terminal statuses: pending, starting, running, waiting
A waiting status means the Agent paused for human input. Check pending_human_request on the same response to see what it is waiting on.
Polling interval guidance:
Polling more frequently than once every 5 seconds per key approaches the rate limit (300 requests per minute). If you are monitoring many Runs in parallel, increase the interval or use a webhook instead.

Get notified when a Run finishes (webhooks)

Pass a webhook_url when starting a Run to receive a POST the moment the Run changes state. This avoids polling entirely and is the preferred pattern for production pipelines. Duvo sends run_completed, run_failed, and run_interrupted events (plus human_request events when the Agent needs input), so filter by the event field for the state you care about.
Your endpoint receives a payload that identifies the Run and its outcome — at minimum the event type, the run_id, and the run status. Use the run_id to call GET /runs/{run_id} for the full run record if you need more detail.
For event-driven triggers that start Runs automatically, see Event-Driven Triggers.

Diagnosing a Failed Run

Identify where a Run went wrong

When a Run shows status: failed, retrieve its message log to find the point of failure. GET /runs/{run_id}/messages returns every step the Agent took in chronological order — model decisions, tool calls and their results, HITL events, and the final output.
Reading the last few messages usually shows what happened at the end of the Run. Look for:
  • A tool_call whose tool_result carries an error
  • A message where the Agent describes why it is stopping
  • A human_request near the end with no follow-up response (the run status shows waiting via GET /runs/{run_id} when this happens)

Inspect the Agent’s tool activity

The messages endpoint returns up to 100 messages per page; use limit and offset to page through longer Runs (total in the response tells you how many there are). Each message has a type, role, timestamp, and — for tool steps — tool_call and tool_result objects.

Distinguish a retried success from a Run that never recovered

Duvo retries transient errors automatically. A Run that retried and then succeeded shows status: completed — you will not see intermediate retry attempts in the status field. To confirm whether a Run went through retries, check the message log for repeated identical tool_calls with error results followed eventually by a successful result. A Run that exhausted all retries shows status: failed with the final tool error in the message log. See Retries, Failures, and Skipped Steps for the full retry behavior reference.

Surface Runs that need attention

The Runs list supports an has_issues filter and an issue_severity filter (critical, medium, low), so you can pull the Runs Duvo flagged for quality or reliability concerns without reading every log:
The full evaluation detail behind a flagged Run is shown in the Runs List UI; the API exposes the flags for filtering, not the per-criterion scores.

Count Runs by status for an Agent

Use GET /teams/{teamId}/runs with the agent_id filter to retrieve Runs for a specific Agent, then count by status. The list response returns Runs under data with a total count.
Sample output:
A failure rate above 10% for a well-established Agent usually signals a Connection Login issue, a change in the upstream data format, or an external API outage.

Page through Runs in a time window

The list endpoint uses offset-based pagination and accepts a since parameter (an ISO timestamp) to bound results to a time window. Page with limit=100 until you have read total rows.
Use this as the basis for a nightly summary report or a feed into a BI tool.

Measure duration and spot latency regressions

The run record exposes started_at and completed_at timestamps; compute duration from the two. A jump in average duration usually means an external service your Agent depends on has slowed down.

Integrating with Your Observability Stack

Send Run events to Datadog, Grafana, or Splunk

Duvo does not have a native push connector for third-party observability tools. The supported pattern is a pull-based pipeline: a scheduled process that pages through new Runs and forwards them to your tool. Example: forward recent Runs to the Datadog Logs API
Run this as a cron job every 5 minutes to keep your Datadog dashboard current with a maximum 5-minute lag. For Splunk, replace the send_to_datadog call with an HTTP Event Collector (HEC) POST. For Grafana Loki, use the Loki push API with the same payload shape.

Use run_id as your correlation key

Duvo does not currently expose OpenTelemetry trace IDs in API responses. Use run_id as the stable identifier to correlate Duvo events with records in your SIEM or log tool.
For a full SIEM integration walkthrough — including exporting actor events (logins, role changes) and builder events (AOP edits, publishes) — see Audit Log and Activity Tracking.

Known Monitoring Gaps

These capabilities are not yet available via the public API. Each row includes the current workaround.

Running Agents via API

Starting Runs, uploading files, and HITL webhook details

Retries, Failures, and Skipped Steps

How Duvo handles transient errors and permanent failures

Audit Log and Activity Tracking

SIEM integration, actor and builder events, CSV/JSON export

Event-Driven Triggers

Trigger Runs automatically from file drops, status changes, or Slack messages

Team Insights

Aggregated metrics, completion rates, and cost trends across your team