Runs

A run is one execution of a flow. Every poll, every webhook, every manual trigger creates exactly one run. Runs are the single source of truth for what APIXX did, when, for whom, and with what result.

What's a run

Each run is durable, immutable, and addressable by ID. We retain run metadata for 90 days on standard plans and 13 months on enterprise plans. Payload bodies are retained for 7 days unless you've enabled extended retention.

Status values

Anatomy of a run

Every run detail page surfaces:

• Trigger — schedule tick, webhook, manual, or API call (with caller ID).
• Cursor window — the updated_since / updated_until bounds for this read.
• Records processed — read, transformed, written, deduped, skipped.
• Duration — wall-clock plus a breakdown for read, transform, write.
• Payloads — the raw inbound trigger payload and any captured request/response samples.
• Errors — per-record failures with the offending field path and the raw error from the destination.
• Log — structured CloudWatch lines, filterable by level.

Filtering & search

The Runs list defaults to the last 24h. Filter by flow, status, time range, or trigger type. Use the search box for a run ID or the substring of an error message — server-side full-text indexes return results in well under a second.

Retries

Default policy: exponential backoff (1s, 5s, 30s, 5m, 30m, 2h) for up to 24 hours on transient failures (5xx, network, throttling). Permanent failures (4xx validation, auth) do not retry — they require human action.

• Retry button on any failed run replays it from the same cursor.
• Partial runs only retry the failed records, not the whole batch.
• You can edit the policy per flow under Flow → Settings → Error handling.

Error categories

Alerting

Configure per-flow alerts from Flow → Settings → Alerts. Channels include email, Slack, PagerDuty, and generic webhooks. Triggers include "any Error run," "Nth consecutive Partial," "SLO burn," and "no successful run in N minutes" (great for catching silent failures).