Reference

How delivery logs work

Every Slack post attempt is recorded in a per-form log. This page documents the columns, statuses, and Slack response decoding.

What the log records

A row per response received by RouteForms. The row captures everything we know at the point of delivery, when the response arrived, which rule matched, where it tried to post, and what Slack said in reply.

The log is per-form. Each form's dashboard has its own log; there's no merged view across forms today. Sorting is reverse-chronological by default.

Columns

ColumnWhat it shows
ReceivedISO timestamp the response landed in RouteForms.
StatusOne of DELIVERED, FAILED, SKIPPED, PENDING. See below.
Matched ruleWhich routing rule fired, or '(default)' if none matched. Empty for SKIPPED.
DestinationSlack channel label (e.g. #hot-leads) plus a masked webhook URL.
Slack HTTPThe status code Slack returned (200, 400, 404, 429, 500, etc.).
Slack responseThe first 2KB of the body Slack returned. Useful for decoding errors.
AttemptsHow many times we tried to deliver. Usually 1; higher for retried failures.
ActionsRetry button (failed rows), View payload (all rows).

Statuses

DELIVERED

Slack accepted the post (HTTP 200, body ok). The message landed in the channel referenced by the destination webhook. Green check icon in the dashboard.

FAILED

Slack rejected the post or the request errored. The row carries the Slack HTTP status and response body. The Retry button re-attempts the delivery (see retries). Red X icon.

The most common causes per Slack response:

  • HTTP 404 + no_service / no_team, webhook revoked or deleted on the Slack side.
  • HTTP 400 + invalid_payload, usually a malformed Block Kit body or wrong Content-Type.
  • HTTP 429. Slack rate-limited the webhook. Backoff applies.
  • HTTP 5xx, transient Slack-side error.

Full error vocabulary at /tools/slack-webhook-error-decoder.

SKIPPED

No webhook was configured for the matched destination. The submission was accepted (so the response isn't lost), but no Slack post was attempted. Two reasons:

  • The form has no default webhook AND no rule matched.
  • The matched rule's destination has an empty webhook URL.

Grey dash icon. You can either configure the missing webhook and click Retry, or leave the row as-is for review. Skipped rows count against your monthly response quota.

PENDING

The response is in the queue but hasn't been delivered yet. This is a transient state, usually you only see it on the in-flight row immediately after a submission. If a row sits in PENDING for more than ~30 seconds, our processing backed up; check status or the dashboard banner.

Viewing the original payload

Click View payloadon a row to see the JSON RouteForms received from Apps Script. Useful when a routing rule didn't match the way you expected, the payload shows you the exact field names and values as they arrived.

Filtering

The log supports the following filters in the dashboard:

  • Status: DELIVERED / FAILED / SKIPPED / PENDING.
  • Destination: the channel label or webhook the row tried to post to.
  • Matched rule: filter to rows that matched a specific rule, or filter to default-destination rows.
  • Date range: start and end timestamps.

Filters compose, combining Status = FAILED with a date range is the standard incident-investigation flow.

Retention

The log keeps rows according to the active plan:

PlanRetention
Free30 days
Solo90 days
Agency180 days

Rows older than the retention window are deleted automatically. There's no undo. For long-term archiving (compliance, audit), export the log via the dashboard's CSV export button.

API access

The log isn't exposed via a public API today. CSV export is the supported way to get data out for analysis or archiving. A read-only API is on the roadmap; contact us if it's blocking a workflow.