Free Google Forms → Slack setup checker
Pre-flight check for your whole pipeline. Verify the Slack webhook, the Apps Script trigger, the form response, and your routing rules, one dashboard, exact fix per item. Run it before you go live.
We POST a tiny test payload server-side.
Read these from Apps Script → Triggers (clock icon).
JSON, a Sheets row (TSV), or key: value lines.
Field names must match the sample response exactly.
Updates live as you edit. The Slack ping runs when you click “Run setup check”.
Paste your Slack incoming webhook URL above to verify it's alive.
onFormSubmit / From form / On form submit is the canonical setup.
Name, Email, Budget, City
Optional. Add rules below if you want to route by answer.
The setup-time failure mode no symptom tool catches
The decision-tree troubleshooter and the diagnostic checklist both assume something has gone wrong, a symptom has shown up and you're working backward to a fix. The pre-flight check is the opposite: you haven't shipped yet, you want to know if you would have shipped a working setup. It catches the silent failures that don't show up in any single tool's view.
- Field-name drift. Your routing rule says
Budgetbut the question on the form isBudget (USD). The Apps Script trigger fires, Slack accepts the post, but the routing rule never matches, so the response falls into the default channel forever. The setup checker compares rule field names against the sample response and flags the mismatch. - Trigger configured wrong but webhook works.A common setup mistake: webhook is fine, but the trigger's event type is “On open” or source is “Time-driven”. The webhook checker passes; the script never fires. The setup checker validates both axes together.
- Webhook is fine, trigger is fine, but no routing destination set. A rule with a field and operator but no destination channel does nothing in production. The setup checker catches empty destinations before they ship.
Three useful moments
- Before going live with a new form. Fill the four panes, hit Run, fix what the dashboard flags. ~2 minutes vs the 30-minute debug session if something silently breaks after launch.
- After inheriting an existing integration.A teammate built the setup and you're now responsible for it. Paste the config; if it's all green, you've got a working baseline.
- Before publishing the form publicly.You've tested with internal submissions but haven't opened it to the world yet. Last sanity check before traffic hits.
And when RouteForms picks up
A pre-flight check is point-in-time. Once you're live, things drift, webhooks get rotated, form questions get renamed, Apps Script triggers get accidentally deleted. The setup checker can't tell you about a webhook that worked on Tuesday and got revoked on Thursday.
That's what RouteForms's per-form delivery log is for: every Slack post recorded with the destination, the matched rule, and Slack's HTTP response, so drift shows up as a row turning red the first time it happens, not as missing leads weeks later. Failed deliveries get a Retry button; paid plans get an email when a streak of failures starts.
Frequently asked questions
What does this tool actually do?▾
It's a pre-flight readiness check for the whole Google-Forms-to-Slack pipeline. You fill four panes, the Slack webhook URL, the Apps Script trigger configuration (function name, event source, event type), a sample form response, and optionally your routing rules, and the dashboard on the right gives you a green / yellow / red verdict per area with the exact fix for anything that's wrong. Run it before you go live so you don't ship a broken setup, or run it after a teammate inherits the integration so they can verify it without trial and error.
How is this different from the other diagnostic tools?▾
Each existing tool covers one slice. The webhook checker pings one URL. The Apps Script trigger checker verifies one trigger. The checklist is a 9-item manual audit. The troubleshooter is a decision tree for an existing symptom. The setup checker rolls the first three into a single pre-flight dashboard with cross-checks, for instance, it verifies that your routing rule field names actually exist in your sample response, which no other tool does. Use it before going live; use the others when something's already broken.
Does it actually call Slack?▾
Yes. When you click 'Run setup check', we POST a tiny test payload to your Slack webhook URL server-side (same endpoint our /tools/slack-webhook-tester uses) and read back the response. If Slack accepts it, you see the message in the channel and the dashboard shows green. If Slack rejects, the dashboard surfaces the decoded error — 'webhook revoked', 'invalid_payload', 'rate-limited', etc. The other panes (trigger, response shape, rules) evaluate client-side without sending anything.
Is it safe to paste my webhook URL here?▾
Yes. The check happens server-side from our infrastructure with the same protections the webhook checker uses: a single innocuous payload, no storage of the URL after the request, and a refusal to ping private IPs, loopback, cloud metadata endpoints, or .internal / .local hostnames.
What does the routing rules pane check?▾
Two things, both critical for routing to actually fire in production. (1) Every rule has a destination, a rule without a channel doesn't route anywhere. (2) Every rule's field name matches a field in your sample response, case-insensitive, whitespace-trimmed. This is the silent failure mode: a rule that says 'Budget' won't match a question titled 'Budget (USD)', and routing silently falls through to the default channel. The setup checker catches that before you ship.
What if the verdict says 'Ready to go live' but submissions still don't reach Slack?▾
Three rare reasons left to check. (1) The trigger may have been wiped by an unrelated script edit since you last looked, re-open Apps Script → Triggers and confirm it's still there. (2) Slack may be silently filtering bot posts due to a workspace admin policy. (3) The webhook may have been bound to a different channel than the one you're watching. Our /tools/form-to-slack-troubleshooter walks you through these symptoms.
Can I save the dashboard?▾
No, the page is stateless. Refresh resets everything. The intent is fast pre-flight, not long-term tracking. If you want a persistent record of every Slack delivery (status code, retry button, failed-alert email), that's what RouteForms's per-form delivery log is for.
Does this work for non-Slack webhooks?▾
The Slack-side check sends a Slack-formatted Block Kit payload and decodes Slack's error vocabulary. For a custom HTTPS endpoint, the checker still pings, but the diagnosis will only tell you the HTTP status and response body, not domain-specific advice. The Apps Script trigger and routing rules panes work identically regardless of the destination.
Pre-flight is the start, monitoring is the rest
RouteForms runs the same setup invisibly and records every delivery to a per-form log. Free for 30 responses a month.
Keep reading
Just the Slack-URL ping in isolation, with the full decoded response and latency.
Just the trigger-configuration verdict in isolation, with common-mistake guidance.
The 9-item manual audit for when something's already broken and you want a flat walkthrough.
All the real options for delivering Google Form responses to Slack, ranked by fit.