← Back to documentation

Observability

Track endpoint health with Activity charts, outcome filters, and log analysis.

8 min read

Use Request activity to detect failures quickly and confirm fixes.

Purpose

This guide helps you:

  • Read request volume trends.
  • Investigate request outcomes and error reasons.
  • Isolate endpoint-specific problems.

Prerequisites and permissions

  • Signed-in access to Request activity.
  • At least one endpoint receiving traffic.

Step-by-step workflow

1. Open Request activity

The page has two views:

  • Volume Chart
  • Request Log

Both support endpoint filtering.

2. Analyze request volume

In Volume Chart:

  1. Choose endpoint (All endpoints or one endpoint).
  2. Choose window (Month, Week, Day).
  3. Navigate previous/next windows.
  4. Review total, average, and peak counts.

UI cue: chart labels and summary metrics update immediately when endpoint/window changes.

3. Investigate request outcomes

In Request Log:

  • Use outcome filters (All, Success, Pending, Errors, Test).
  • Review Outcome and Error reason columns.
  • Page through results for large datasets.

Current outcomes:

  • ACCEPTED — Request passed all checks and was dispatched to outputs.
  • AUTH_FAILED — Inbound authentication failed (wrong credentials, expired HMAC signature, or SPF/DKIM/DMARC enforcement rejection for email endpoints).
  • CAPTCHA_FAILED — Human verification (Turnstile/reCAPTCHA) token was missing or invalid.
  • DELIVERY_FAILED — Request was accepted, all delivery attempts have settled, and at least one output target failed.
  • EMAIL_INGESTION_ACCEPTED — Inbound email was accepted and dispatched. It may appear as PENDING while output deliveries are still in progress.
  • EMAIL_INGESTION_DISABLED — Historical outcome for email sent to a disabled endpoint. Current disabled endpoint hits are omitted from request activity.
  • EMAIL_INGESTION_REJECTED — Inbound email was rejected by an email-specific policy or setup check, such as sending to a non-email endpoint, using an unsupported body-as-payload format, an empty/HTML-only body where text/plain is required, or a null SMTP sender rejected by an allow-list. The specific reason is in the log entry's errorReason field.
  • FAILOVER_TRIGGERED — A webhook output exhausted all retries and its failover destination was activated. It may appear as PENDING while the failover delivery is still in progress.
  • FIELD_VALIDATION_FAILED — Payload fields failed a configured validation rule (wrong type, missing required field, regex mismatch).
  • IP_BLOCKED — The originating IP address is not on the endpoint's IP allowlist.
  • MALFORMED_FORM_PAYLOAD — Request body with application/x-www-form-urlencoded could not be parsed.
  • MALFORMED_JSON_PAYLOAD — Request body with application/json was not valid JSON.
  • MALFORMED_XML_PAYLOAD — Request body with application/xml or text/xml was not valid XML. The error reason is Malformed XML body.
  • MALFORMED_QUERY_PARAM — Query parameter parsing failed (e.g., invalid Base64 in query parameter mode).
  • MISSING_REQUIRED_HEADERS — A required request header declared on the endpoint is missing or has the wrong value.
  • METHOD_NOT_ALLOWED — The HTTP method of the incoming request does not match the endpoint's configured method.
  • PAUSED — Historical outcome for paused endpoint hits. Current paused endpoint hits are omitted from request activity.
  • PENDING — Request was accepted and at least one regular or failover delivery is still in progress. Once all deliveries settle, the row moves to the final outcome (ACCEPTED, EMAIL_INGESTION_ACCEPTED, DELIVERY_FAILED, or FAILOVER_TRIGGERED).
  • PAYLOAD_TOO_LARGE — The event exceeded the maximum allowed size for your plan (256 KB Sandbox/Solo, 512 KB Team trial/Team, 1 MB Scale).
  • QUOTA_EXCEEDED — The monthly accepted-event quota was already exhausted when the event arrived.
  • RATE_LIMITED_ENDPOINT — The endpoint's per-minute rate limit was exceeded. Request returns 429 with a Retry-After header.
  • REQUEST_BODY_FILTER_FAILED — The request body did not satisfy a configured body filter rule.
  • SUBSCRIPTION_BLOCKED — The organization's subscription is inactive, expired, or otherwise blocked from relaying.
  • TEST_ACCEPTED, TEST_REJECTED, TEST_RATE_LIMITED — Outcomes from the relay-target Send test button (not real traffic).
  • UNSUPPORTED_MEDIA_TYPE — The incoming Content-Type does not match what the endpoint expects.
  • WEBHOOK_INGESTION_DISABLED — A webhook-style request hit an enabled endpoint that has webhook ingestion disabled. Disabled endpoint hits are omitted from request activity.

Note: Email-sourced relays use the same granular validation outcomes where possible. Body filters log REQUEST_BODY_FILTER_FAILED, field validations log FIELD_VALIDATION_FAILED, SPF/DKIM/DMARC and non-empty disallowed senders log AUTH_FAILED, and generic email setup/policy rejects log EMAIL_INGESTION_REJECTED.

Requests rejected solely because an endpoint is disabled or paused do not create request activity rows.

Additional filters

The request log supports additional filters to narrow results:

  • Outcome multi-select: Filter by one or more specific outcomes. The existing category shortcuts (success, pending, errors, test) are still supported. You can also pass a comma-separated list of exact outcome names (e.g. ACCEPTED,DELIVERY_FAILED).
  • Source IP filter: Enter an IP address to show only requests from that specific originating IP.
  • Error search: Type a substring to filter logs by error reason, outcome enum name, or outcome display label (case-insensitive). Results update as you type (debounced).

All filter state is reflected in the URL query string for deep-linking.

CSV export

The Export CSV button appears in the Request Log panel header, next to the "Clear filters" affordance. Clicking it downloads a CSV file containing all log entries that match the current filters and time window.

Columns exported (in order): timestamp_utc, endpoint_id, endpoint_name, outcome, http_method, source_ip, error_reason, request_id. The http_method value may be blank for historical rows or activity that is not tied to a specific inbound HTTP method.

Row cap: Up to 100,000 rows are exported. If your filters would return more, the file is truncated and a comment line # truncated at 100000 rows; narrow your filters is appended. Use tighter date ranges or outcome filters to reduce result size.

Exports may be temporarily limited during high-volume use. If you see a retry message, wait before starting another export.

4. Drill down by endpoint

  1. Filter to one endpoint.
  2. Compare outcomes against endpoint settings (method, auth, captcha, validation, outputs).
  3. Use trend direction to confirm recovery after changes.

Expected result and verification checks

  • You can distinguish input rejection vs destination-delivery failures.
  • You can scope incidents to one endpoint, one provider, or broader impact.

Data retention and privacy:

  • A metadata-only activity trail and delivery outcomes are retained for 30 days.
  • Payload bodies are excluded from the activity trail. They are processed in delivery and retry queues while events are being forwarded.
  • A failed queue message can remain in an operational dead-letter queue until it is remediated or purged.

Common issues and fixes

  • Traffic drops to zero: verify sender integration and endpoint URL.
  • METHOD_NOT_ALLOWED spikes: sender method drifted from endpoint setting.
  • PAYLOAD_TOO_LARGE spikes: sender payloads exceed the endpoint limit for the current plan.
  • MALFORMED_FORM_PAYLOAD spikes: sender is posting invalid application/x-www-form-urlencoded data.
  • MALFORMED_XML_PAYLOAD spikes: sender is posting invalid XML or a body that does not match the endpoint's XML payload format.
  • DELIVERY_FAILED spikes: inspect relay target auth/URL/TLS and destination uptime.

Related guides

← Back to documentation