Error Inbox
A single place to review every integration error, the offending payload, and the upstream system that rejected it.
What it covers
The Error Inbox at /errors consolidates every failure across your account into one triage view. Each row shows the failing flow, the source system, the error code & message, and a sample of the payload that caused the failure.
Error sources
| Source | Tag | What's captured |
|---|---|---|
| Flow | enterprise | Run-level failures and per-record rejections from the flow error bucket. |
| Connector | lambda | Errors logged by the connector Lambda when the destination API rejects a record. |
| Ingestion API | ingest | Events posted to /api/public/data/ingest that the normalizer rejected (422). |
How errors are collected
A scheduled error-sweep-tick job runs every few minutes. It scans recently errored runs from the flow cache, reads the error files written to S3, extracts the payload + error message from each rejected record, and writes them to the data_run_error table along with any ingestion-API rejections.
Deduplication & counts
Errors are deduplicated by a content hash of (source, run, code, message, payload fingerprint). Repeated occurrences increment the occurrence count and update last seenrather than creating duplicate rows.
Acknowledging errors
Open the detail page and choose Acknowledge once an error has been reviewed or fixed. Filtering by Open hides acknowledged rows so triage stays focused. Acknowledgement is reversible.
Retention
The sweep job looks back 24 hours. Stored errors persist indefinitely until manually cleared — recurring failures will refresh the last seen timestamp on the existing row.