Free tool · no sign-up

Slack Webhook Tester

Paste your Slack webhook URL. Customise the message, channel override, sender name, and emoji — or paste your own JSON. We POST it to Slack and report the status, latency, response body, and a plain-English diagnosis of Slack's error codes.

Slack webhook URL

HTTPS only. The POST runs server-side — we don't store the URL, log it, or surface it in analytics. The URL is masked when you click away from this field.

Mode

Message text

Channel override

Sender name

Icon emoji

Channel/username/icon overrides only work on legacy custom-integration webhooks. New Slack-app webhooks ignore them — the destination and identity are bound to the URL.

Payload preview

{
  "text": "Hello from Slack Webhook Tester :wave:"
}

When to use this

The two debugging moments

Right after creating a webhook: you've generated the URL in Slack but haven't wired it to anything yet. Send a test from here, confirm the channel shows the message, then go set up your Apps Script.
When deliveries silently stop: submissions come into your form but don't appear in Slack. Run the checker; if Slack rejects with no_service or invalid_token, the webhook was revoked or deleted on the Slack side.

Common results

What each verdict means

Delivered (HTTP 200, “ok”): Slack accepted the message. You should see the test message in the channel the webhook is bound to.
HTTP 404 / no_service / no_team: Slack doesn't recognise the URL. It was likely revoked or deleted; generate a new one.
HTTP 400 / invalid_payload: the URL is good but Slack didn't like the JSON shape. Almost always a missing or wrong Content-Type header in the caller.
HTTP 429: Slack rate-limited you. Back off and retry.
Timeout: the endpoint took longer than 5 seconds to respond. For a webhook receiver that's a code smell, webhooks should ack fast.

The checker maps each of these to plain English so you don't have to memorise Slack's error vocabulary.

FAQ

Frequently asked questions

What does the checker do?▾

It POSTs a tiny test payload to the URL you provide and reports back what happened. You get the HTTP status code, response latency, the response body the endpoint returned, and a plain-English diagnosis of common failure modes, especially Slack's invalid_payload, no_service, no_team, and rate-limit responses.

Is it safe to paste my webhook URL here?▾

Yes. The check happens server-side from our infrastructure; we don't store the URL after the request finishes. We send a single innocuous payload, for Slack URLs, a 'webhook check' message; for everything else, a plain JSON object identifying RouteForms as the sender. No surprise traffic to your endpoint.

What URLs are allowed?▾

Any public HTTPS URL. We block private IP ranges, loopback addresses, link-local IPs, cloud metadata endpoints, and .internal / .local hostnames, both to protect ourselves from open-proxy abuse and to refuse anything that would obviously fail from outside your network.

What happens with a Slack incoming webhook?▾

We send a Slack-formatted Block Kit message. If Slack accepts it (HTTP 200, body 'ok'), you'll see a quick confirmation message in the channel and the checker reports success. If Slack rejects (no_service, invalid_payload, etc.), we map the error to plain English so you know what to fix.

What about non-Slack webhooks?▾

We send a generic JSON object, message, from, timestamp, note. The checker reports the HTTP status and response body so you can verify your endpoint received and accepted the call. Useful when you're using Apps Script to POST to a custom server or a non-Slack service.

How long does the check take?▾

Up to 5 seconds. If the endpoint takes longer to respond, we abort and report a timeout, which is itself useful information, webhooks should respond well under a second.

Have we been delivering when you expected?

RouteForms records every Slack delivery attempt with the status code and Slack's response. Failed ones get retried in one click, and on paid plans, an email tells you when it happens.

Start free →See pricing