Testing guide

How to test a Google Forms to Slack notification

Three phases: pre-flight every piece in isolation, then send the canonical live test, then set up ongoing monitoring so silent failures surface within minutes instead of weeks. The order matters.

Start free →

Pre-flight in 30 seconds, no quota used
Live test from real form submission
Ongoing monitoring catches silent failures

TL;DR

The three phases of testing

Pre-flight: validate each piece (webhook URL, Apps Script trigger, routing rules, message template) without involving Google Forms. Catches misconfiguration before you submit anything.
Live test: submit a real test response. Confirms the end-to-end pipeline works on the real submission path.
Ongoing monitoring: failure alerts, delivery log audits, the pre-flight check after every config change. The slow leak guard.

Phase 1

Pre-flight, validate each piece in isolation

Pre-flight tests catch the four classes of misconfiguration that account for the vast majority of broken pipelines: a malformed webhook URL, a mis-installed Apps Script trigger, routing rules that don't match the field shape, and a message template referencing a field key that doesn't exist. Each takes seconds; running all four before the live test saves the round-trip of "submit, wait, debug, fix, repeat".

1
Validate the Slack webhook URL
Paste the URL into /tools/slack-webhook-tester , it sends a server-side POST and reports Slack's exact response. A 200 means the URL is good; any error message paired with /tools/slack-webhook-error-decoder identifies the cause.
2
Check the Apps Script trigger configuration
Open Apps Script → Triggers, or paste the trigger config into /tools/apps-script-trigger-checker. The function should be onFormSubmit or whatever the RouteForms install script registered; the event type must be On form submit. The most common mistake here is On open, which fires when the form is loaded for editing, not on submission.
3
Simulate routing rules against a sample payload
/tools/routing-rule-simulator takes your rules and a sample submission and walks through which rule fires (or why none fire). For multi-rule forms, this is faster than submitting variations of the form until you find a miss.
4
Run the all-in-one setup checker
/tools/google-forms-to-slack-setup-checker rolls webhook + trigger + rules into a single dashboard. Useful as the "is everything still green?" check before bigger config changes.

Phase 2

Live test, one real submission, end-to-end

The pre-flight phase tells you each piece works in isolation. The live test confirms the pieces work together on the real path. One submission, three things to verify.

1
Open the form and submit a test response
Use representative test values, not just "test test test" in every field. If routing rules depend on specific values (a "Plan tier" dropdown, a "Country" field), pick a value that exercises the rule path you want to verify. For VIP routing, submit as a VIP. Mark the test as a test in the body if you can, so anyone reading the Slack channel knows it's not a real customer.
2
Watch the Slack channel for the message
Within ~5 seconds, the formatted message lands. Verify three things visually: (1) the right channel, (2) the right template / mentions / icon, (3) all field values rendered as expected. If a field shows as blank or as the literal placeholder string {{response.field['…']}}, the template references a field key that doesn't exist on this form.
3
Check the RouteForms delivery log
Open the form → Delivery log. The new row should show DELIVEREDwith Slack's HTTP 200 OK and the rendered payload. Expand the row to see the full payload that was sent, useful when the Slack rendering doesn't match expectations and you want to confirm whether the bug is in the template, in the payload, or in Slack's rendering.

If the live test fails

The diagnostic ladder

Did the Apps Script trigger fire?Apps Script → Executions tab. A completed row means it fired; no row means the trigger isn't installed or isn't bound to this form.
Did the trigger error? A failed row in Executions carries an error message. Paste it into /tools/apps-script-error-decoder for the plain-English fix.
Did RouteForms receive the submission? The delivery log shows every received submission. If the trigger fired but no log row exists, the script is sending to the wrong endpoint, reinstall to refresh the inbound webhook URL.
Did Slack reject the payload? A delivery log row with status FAILED carries Slack's exact error. Decode it via /tools/slack-webhook-error-decoder.
Did the full diagnostic flow not find it? /tools/form-to-slack-troubleshooter walks through the entire decision tree as a guided interview.

Phase 3

Ongoing monitoring, catching silent failures

A pipeline that works on day one can break silently on day 30, a Slack channel gets archived, a webhook gets revoked, a form question gets renamed. The monitoring you set up here decides whether you find out in minutes or weeks.

Failure alerts(paid plans). Enable on the form's Settings tab. After N consecutive delivery failures (default: 3), an email goes to the form's owner and any added teammates. This is the single most useful thing, it converts "we missed a week of leads" into "an email arrived this morning".
Delivery log audit cadence. Open the delivery log weekly for high-value flows; monthly otherwise. You're scanning for FAILEDrows that didn't trip the alert (single failures, intermittent issues).
Pre-flight check after every config change. The 30-second setup-checker run is cheap insurance, webhook URL changed, routing rule edited, question renamed on the form. Run it; don't wait for the first failed submission to find out.
One annual live test. Once a year, submit a real test response even when nothing has changed. Catches drift you didn't know about. Slack API deprecations, Apps Script runtime changes, your workspace admin tightening permissions.

FAQ

Frequently asked questions

What's the difference between a pre-flight test and a live test?▾

A pre-flight test validates each piece in isolation, does the webhook URL accept a POST, is the Apps Script trigger configured for form-submit, do the routing rules match the fields you expect, without involving a real Google Forms submission. A live test is an actual form submission that flows the whole pipeline end-to-end. Pre-flight catches misconfiguration in seconds without polluting the delivery log; the live test confirms the real path. You want both, in that order.

Can I test without using up my free-plan response quota?▾

Pre-flight tests don't count, they use the dashboard's test endpoint, not the form submission path. The single live test does count, but Google Forms test responses count the same as real ones, so just submit one. After the first successful live test, switch to pre-flight monitoring for subsequent verifications.

Why does the Slack message show up in delivery log as DELIVERED but never appear in the channel?▾

Three causes, in order of likelihood. (1) The webhook is bound to a different channel than you think. Slack confirms HTTP 200 because the post succeeded, just not where you expected. Open the webhook in Slack's app settings and check 'Post to channel'. (2) The channel is muted in your client; check on another teammate's machine or via web. (3) The post landed in the channel but in a thread you're not subscribed to (rare; only if the template includes a thread_ts). Start with (1), it's the answer 80% of the time.

Does test mode skip routing rules?▾

No. The pre-flight test simulates a payload with the field values you provide; routing rules evaluate against that payload the same way they do for real submissions. This is intentional, testing rules without applying rules wouldn't catch the bugs you're testing for. The routing rule simulator (linked below) is the explicit visual tool for stepping through which rules fire for a given payload.

How do I test the Apps Script trigger without submitting a form?▾

Open the Apps Script project → Triggers tab. The trigger config (function name, source = your form, event type = On form submit) shows what's wired up. The Trigger checker tool reads the same config and explains it in plain English. Beyond config validation, you can run the installRouteForms function manually from the Apps Script editor, it executes the install code path without firing the form-submit trigger, so it validates auth and connectivity to the RouteForms endpoint.

What should I check after the test passes?▾

Three things: failure alerts are enabled (paid plans), the delivery log retention covers your audit window, and at least one teammate is added to the form in RouteForms so the alerts have an additional recipient. The third matters more than people think, if the only owner's email is silent for a week, failures can stack up unseen.

How often should I re-test in production?▾

Run a pre-flight check (~30 seconds) whenever you change anything: webhook URL, routing rules, message template, or the form's question structure. A monthly end-to-end live test is the right cadence for low-stakes flows; for revenue-critical flows (lead alerts, support tickets), every two weeks is more honest. The delivery log surfaces real-world failures faster than scheduled tests, the test is the last-line check, not the primary signal.

What does the delivery log show if Slack returns an error?▾

The exact HTTP status, Slack's error string (invalid_payload, channel_not_found, no_service, etc.), and the rendered payload that was sent. Paste the error string into the Slack webhook error decoder for the plain-English fix. RouteForms also retries transient failures (5xx, rate limits) automatically with exponential backoff; the log shows each retry attempt so you can see the difference between "Slack is having a moment" and "your config is broken".