← 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, 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 but delivery to at least one output target failed after all retries.
  • EMAIL_INGESTION_ACCEPTED — Inbound email was accepted and dispatched.
  • EMAIL_INGESTION_DISABLED — Email was sent to an endpoint that does not have email ingestion enabled.
  • EMAIL_INGESTION_REJECTED — Inbound email was rejected (disabled endpoint, allowed-sender mismatch, SPF/DKIM/DMARC failure, body-filter or field-validation failure in body-as-payload mode). The specific reason is in the log entry's errorReason field.
  • FAILOVER_TRIGGERED — A webhook output exhausted all retries and its failover target was activated.
  • 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 — The endpoint was paused (manually, by auto-pause from an alert, or during a maintenance window) when the request arrived.
  • PAYLOAD_TOO_LARGE — The request body exceeded the maximum allowed size for your plan (256 KB Trial/Basic, 512 KB Pro, 1 MB Ultimate).
  • 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.
  • 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 endpoint that has webhook ingestion disabled.

Note: For email endpoints, all validation failures (body filters, field validations, allowed-sender checks, SPF/DKIM/DMARC enforcement) are reported as EMAIL_INGESTION_REJECTED. Check the errorReason column for details.

For HTTP webhook endpoints, validation failures use the specific outcomes (FIELD_VALIDATION_FAILED, REQUEST_BODY_FILTER_FAILED, etc.). For email endpoints, all ingestion failures — including failed body filters, field validations, allowed-sender checks, and SPF/DKIM/DMARC enforcement — are reported as EMAIL_INGESTION_REJECTED. The specific failure reason is in the log entry's errorReason field.

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, 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 reason search: Type a substring to filter logs by error reason (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, source_ip, error_reason, request_id. The http_method column is not included — PayloadRelay does not store the inbound HTTP method in activity logs.

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:

  • Activity data is retained for 30 days.
  • Request payload bodies are not stored.

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