What's new in Relaycast

Until today, replaying failed deliveries meant clicking through them one at a time — fine for a blip, miserable after an incident. The delivery timeline now has checkboxes. Filter by endpoint, status, and time range, select up to 500 deliveries, and hit Replay selected. Deliveries are re-sent in their original order, and every replay carries the same idempotency key as the first attempt so a consumer that already processed an event can safely drop the duplicate.

The same operation is available from the CLI, which is where most of you will want it after a long outage window:

relaycast replay --endpoint checkout-live \
  --status failed \
  --since 2026-08-25T00:00:00Z

Replays respect each endpoint’s rate limit and run through the normal retry pipeline, so a replay can never stampede an endpoint that is still recovering. A progress panel shows sent, acknowledged, and failed counts as the batch drains, and an Abort button stops the remainder instantly.

Every bulk replay is recorded in the audit log with who started it, the filter that selected the deliveries, and the final counts — useful when you are writing the post-incident review an hour later.

A sharp-eyed customer reported that deliveries retried across a secret rotation could arrive signed with the retired secret after the 24-hour grace window ended. The cause: retries reused the signature computed at first attempt instead of re-signing at send time. If your consumer only checked the current secret, those late retries failed verification and looked like tampering.

Retries are now re-signed with the endpoint’s current secret at the moment they leave our edge, and during the grace window both the current and previous secrets validate. If you use the SDK, verification already checks every secret you pass:

import { verifySignature } from '@relaycast/sdk';

const event = verifySignature(rawBody, request.headers['x-relaycast-signature'], {
  secrets: [process.env.RELAYCAST_SECRET, process.env.RELAYCAST_SECRET_PREVIOUS],
});

No action is needed on SDK 3.4 or later. If you verify the HMAC by hand, make sure you accept either secret for the duration of a rotation — the t= timestamp in the header tells you which window a delivery belongs to.

Transforms let you reshape an event before it reaches an endpoint — rename fields, drop internal identifiers, or flatten a payload for a legacy consumer. They were previously written in a small JSON mapping language that nobody loved. As of this release, a transform is just a TypeScript function, edited in the dashboard with full type checking against your event schema:

export default function transform(event: RelaycastEvent): DeliveryPayload {
  return {
    id: event.id,
    type: event.type,
    order: {
      id: event.data.orderId,
      total: event.data.amounts.grandTotal,
    },
  };
}

The editor generates types from your last 500 events, so autocomplete knows what event.data actually looks like in your account, and the Test tab runs your transform against recent real events before you publish it. Publishing is versioned — every delivery records which transform version shaped it, and you can roll back from the same panel.

Under the hood, transforms moved from a pooled interpreter to per-account V8 isolates. The p99 transform overhead dropped from around 40 ms to under 10 ms, and one account’s runaway transform can no longer slow anyone else’s deliveries. Existing JSON mappings keep working and can be converted to TypeScript with one click.

If an endpoint responded a moment after our 10-second delivery timeout, Relaycast marked the attempt failed and scheduled a retry — but the endpoint had actually processed the event. Result: a duplicate delivery a minute later. This bit hardest on consumers doing slow synchronous work such as PDF generation or third-party API calls.

Two changes close the gap. First, every delivery now carries a Relaycast-Idempotency-Key header that stays identical across retries and replays, so consumers can deduplicate with a single unique index:

POST /webhooks/orders HTTP/1.1
Relaycast-Idempotency-Key: dl_9f2c81e7a4
X-Relaycast-Signature: t=1750765200,v1=4c1d22e0b1…
Content-Type: application/json

Second, a late 2xx that arrives within 60 seconds of the timeout now marks the delivery as delivered and cancels the pending retry, so well-behaved-but-slow endpoints stop seeing duplicates entirely.

While we were in the retry scheduler we also added jitter to the backoff curve. Retries for a burst of failures used to land in synchronized waves that could knock a recovering endpoint straight back over; they are now spread across each retry window.

Every endpoint now shows a health score from 0 to 100, computed over a trailing six-hour window from three inputs:

• Success rate — the share of deliveries acknowledged with a 2xx
• Response latency — p95 time to first byte from your endpoint
• Retry pressure — how much of the endpoint’s traffic is retries rather than first attempts

Healthy endpoints sit in the 90s and you never think about them. When a score drops below your pause threshold (default 20), Relaycast stops hammering the failing endpoint, holds its queue for up to 72 hours, and notifies you by email or Slack. Held deliveries replay in order the moment you resume — nothing is lost while your consumer is down.

Auto-pause emits a webhook of its own, so you can wire it into your incident tooling:

{
  "type": "endpoint.paused",
  "data": {
    "endpoint": "ep_live_checkout",
    "healthScore": 12,
    "reason": "success_rate_below_threshold",
    "heldDeliveries": 3141
  }
}

Scores appear on the endpoint list, on each endpoint’s detail page, and in the API. Thresholds are configurable per endpoint, and you can disable auto-pause entirely for endpoints where a thundering herd is someone else’s problem.