Delivery health and retry

A form's Activity page is where you inspect and repair delivery. It's the canonical operational view for webhooks, Google Sheets, Notion, and Slack — Settings is for configuring destinations, not diagnosing them.

Read delivery health

Each configured destination has one dominant status:

• Needs attention — at least one retained delivery exhausted its retries. The card shows the undelivered count and when the live backlog began.
• Retry scheduled — delivery rows are queued or waiting for another attempt. The card shows how many are waiting and the earliest scheduled retry.
• Healthy — no retained failed or pending backlog, and at least one delivery succeeded. The card shows the delivered count and latest success.
• No activity — the destination is configured but has no delivery attempts yet.

The card also shows the provider or safe webhook label and the current destination detail, such as a spreadsheet and tab. Counts cover delivery rows still retained inside the window of up to 90 days. A later success doesn't hide an older undelivered response — the destination stays Needs attention until that row succeeds, is retried, or its target response is deleted.

Failure alerts

When retries are exhausted or an OAuth credential stops being usable, Fillo emails the form notification address, or the workspace owner when no notification address is set. It sends at most one alert for the same form and destination per display day while a live backlog remains.

The alert names the destination, affected count, failure age, and latest error. A normal terminal-failure alert links to Activity. A reauthorization failure links to Settings instead, so a manager can reconnect the provider. Alerts never include response answers.

Inspect recent deliveries

Recent deliveries shows the latest 50 retained handoffs across the form's webhooks and integrations, newest state change first. Each row can include:

• the response event and provider or webhook destination;
• queued, retrying, delivered, or failed status;
• the current destination detail;
• time, attempt count, and the last HTTP status for webhooks;
• the next scheduled retry while pending;
• the bounded provider error; and
• Open response when the target response still exists.

The view covers at most the last 90 days. When more retained rows exist, the footer says only the latest 50 are shown. This is delivery history, not a general audit log — account and schema changes aren't included. Removing a webhook or integration removes its delivery rows, so history for that destination can disappear before the 90-day ceiling.

Repair, then retry

1. Open Activity and read the latest error on the failing destination.
2. Choose Manage destinations to open Settings.
3. Reconnect an expired Google, Notion, or Slack account; change an invalid sheet or Slack channel; or repair the webhook receiver.
4. Return to Activity and choose Retry now on the destination card or exact delivery row.
5. Watch Retry scheduled become Healthy, then verify the destination itself.

Retry now advances scheduled retries and resets terminally failed rows that still have a response or draft target. It never touches delivered rows. A delivery already due or in flight keeps its active claim instead of being started twice. The action is rate-limited and runs through the normal outbox after the request returns.

Retry or re-send responses

The grid's Retry failed requeues only terminally failed destinations for the selected responses. It leaves pending and already delivered rows alone. Use destination-level Retry now when you want to start every scheduled or failed delivery for one destination instead of only the responses currently in the grid.

The response drawer's Re-send is deliberately broader: it sends that response to every current destination again, including destinations that already delivered. Use it only when another downstream copy is intended.

In code

Delivery health and retry are management operations. They're available on the authenticated Activity page, not through the public renderer client or the current Management API. Your webhook receiver should maintain its own durable inbox keyed by X-Fillo-Delivery-Id.

Related

• Webhooks: Verify, acknowledge, and deduplicate webhook requests.
• Google Sheets sync stopped: Repair a revoked account or changed sheet.
• Integrations: Configure the supported response destinations.