Questions before you start

Webhooks fire within seconds of the time you set, not rounded to the next minute like a cron job.

Timeouts, network errors, and 408, 425, 429, or 5xx responses are retried automatically with exponential backoff: 4 retries over ~8 min on Free, 10 retries over ~8.5 h on Pro, and 14 retries over ~33 h on Scale. Other 4xx responses, such as 400, 401, 404, or 422, are a definitive answer from your endpoint, so the webhook is marked failed without retrying. Every attempt is logged with its HTTP status, latency, error, and response body when available.

Yes. Cancel any scheduled webhook from the API or the dashboard before it fires. If a webhook to a URL can’t be delivered, one fix gives every webhook scheduled to that URL the new address, in place: they keep their ID and run time, and the failed one can be sent again. From a failed or canceled webhook, Edit and reschedule creates a corrected copy with a new payload or time.

They work, with trade-offs. In Make, a Data Store and a scenario that checks it on a schedule spend credits on every check, even when nothing is due (Make counts 720 credits a month for an hourly check); the follow-up can be late by up to one interval, and a failed follow-up is not retried unless you build that too. n8n’s Wait node documents no maximum: the run stays paused inside n8n, and you cancel it by stopping that execution. Here each webhook has its own exact time, is canceled with one call, is retried if your endpoint fails, and leaves a log of every attempt. With a few records and a daily check that is precise enough, staying native is fine.

By email, if you want. In Settings → Alerts you pick one of three: “If a webhook can't be delivered” (recommended), “Also at the first failed try”, or “Never”. Either way, the dashboard shows every failure with its full delivery history.

The webhook is marked as failed (as it is right away after a non-retryable 4xx response), and its full delivery history stays visible. Add a business reference when scheduling to reconcile open or failed webhooks against your own database through the API.

Every webhook is saved in our database and queued with Google Cloud Tasks for its run time, so the wait doesn’t depend on our app staying up in between. A webhook is only marked delivered when your endpoint answers with a 2xx, and only marked failed after its retries, so an incident on our side never turns into a false “delivered”. Live status and past incidents are on the status page.

Logs include each webhook’s details, every delivery attempt, HTTP response codes, latency, errors, and response bodies when available. Automated retention is 7 days on Free, 30 days on Pro, and 90 days on Scale. Keep business-critical events in your own system of record.

Webhooks, their payloads and delivery logs are stored in a Postgres database hosted by Supabase. The app runs on Vercel, and Google Cloud schedules the deliveries. Every provider is listed on the sub-processors page. You can export your data or delete your account at any time from Settings.

All plans run on the same production delivery path. A formal SLA is only available through a separate written agreement, so the public plans do not promise an automatic contractual SLA.

One scheduled HTTP request is one webhook, whatever the retries. If a webhook fails and is retried several times, it still counts once against your monthly limit.

Yes. The Free plan requires no payment method. You get 100 webhooks a month, 1 API key, delivery logs, scheduling from the dashboard, and up to 7 days ahead, enough to integrate and test end-to-end before upgrading.

Yes. Upgrades take effect immediately and are prorated. Downgrades apply at the start of the next billing cycle. No contracts, cancel anytime.