The form was for thirty places. It has forty one responses, the last eleven of which are people who think they are registered. Somebody now has to work out who the thirty are, tell the other eleven something, and stop the form taking a forty second.
This is the most common way a Google Form waitlist question starts, and it starts too late. There is no setting in Google Forms that stops accepting responses at a number, which means a waitlist is something the organiser builds rather than something the form does. What follows is what Google actually provides, the three shapes people build on top of it, and the point at which patching stops being worth it.
Google Forms has no seat count, and that is the whole problem
It is worth being precise about what the product does and does not offer, because a lot of advice assumes a setting that does not exist.
Google's own API reference for Forms is the clearest statement of the shape of a form's settings. In version 1 of the Forms API, the entire FormSettings object contains two things: quiz settings and an email collection type. There is no capacity field, no closing date, and no per option limit. At the form level there is a publish setting, and the API exposes a call to publish or unpublish a form. That is the only switch: open, or closed.
So the built in behaviour is binary. A form accepts responses or it does not, and the transition between those two states is a manual act unless something else performs it. Everything called a Google Forms waitlist is one of three ways of arranging for that switch to be thrown, plus a place for the overflow to go.
One further detail is worth knowing if the form is created programmatically. The API reference notes that forms created with the API after 30 June 2026 have an unpublished state by default, so a newly created form will not accept responses until it is published. That is a change in behaviour rather than a new capacity feature, but it catches scripts written against the older default.
Three ways to run a waitlist with what Google gives you
The routes differ in who does the watching, and that is the only difference that matters in practice.
| Route | How the cutoff happens | What it costs |
|---|---|---|
| Close the form by hand | Somebody checks the response count and unticks accepting responses | Only works while somebody is watching; overnight and weekend overshoot is normal |
| An Apps Script trigger on submit | A script counts rows and closes the form, or edits the confirmation message | A script to maintain, running under one person's account, inside published quotas |
| A separate waitlist form | The main form closes, and its confirmation message points at a second form | Two lists that have to be reconciled by hand, and nobody's position is visible |
The manual route is not as weak as it sounds when registration is slow and the cap is generous. Where it fails is the shape most events have, which is a burst of registrations in the first two hours after the announcement and a trickle afterwards. A cap of thirty with a hundred people receiving the email at nine in the morning will be passed before anyone opens the responses tab.
The separate form route is the most common and the least satisfying. It works, in the sense that the overflow is captured somewhere, and it creates a second problem immediately: two lists, no shared numbering, and no way to answer the only question a person on a waitlist ever asks, which is where they stand.
The script route, and what it costs later
An Apps Script trigger is the answer most technical write ups reach for, and it does work. The mechanics are documented: Google lists an installable form submit trigger that runs when a user responds to a form, with two versions of it, one bound to Google Forms itself and one bound to the spreadsheet if responses go to a sheet. The script counts the responses, and past the cap it either unpublishes the form or rewrites the confirmation message so later respondents are told they are on a waiting list.
Before committing to it, read the parts of that documentation that are not about how to write the code.
The trigger belongs to one person. Google states that installable triggers always run under the account of the person who created them, and that a given account cannot see triggers installed from a second account. The automation is therefore invisible to everyone except its author. When that person leaves, changes role, or has their account suspended, the waitlist logic stops and the next administrator cannot find it, let alone fix it.
Email is capped, and the cap is low on a personal account. If the script sends the waitlist notification, the published quotas allow 100 email recipients per day on a consumer account against 1,500 on a Workspace account, with 50 recipients per message either way. A single announcement to a mailing list of two hundred, sent from a personal Gmail account, does not fit.
Runtime is capped too. Total trigger runtime is limited to 90 minutes per day for consumer accounts and 6 hours per day for Workspace accounts, with a limit of 20 triggers per user per script. A registration burst that fires a script on every submission uses that budget, and the failures land in an execution log nobody is reading.
Some submissions do not fire the trigger at all. The same documentation notes that script executions and API requests do not cause triggers to run, so a response submitted programmatically will not be counted by a trigger based counter.
None of this makes the script route wrong. It makes it a piece of infrastructure with an owner and a failure mode, which is a different thing from a setting, and it should be documented as such rather than left in one person's Drive.
What a waitlist needs that a form response does not
Step back from the mechanics and the reason this gets messy becomes clear. A form response is a record of something that happened. A waitlist entry is a record of something that has not happened yet, and unfinished things need state.
A usable waitlist carries four things that a spreadsheet row does not have by default.
A position, and a rule for what position means. Order of submission is the usual rule and the easiest to defend. Whatever the rule is, it has to survive rows being sorted, because the moment somebody sorts the sheet alphabetically the original order is gone unless the timestamp is the authority.
A status. Waiting, offered, accepted, declined, expired, withdrawn. Without this the list cannot answer whether a place has already been given away, which is the question that causes double booking.
An offer with an expiry. When a place is released, it goes to one person with a deadline, not to everyone at once. An offer with no expiry is a place that sits unclaimed while the rest of the list waits. Three days is a common window for events more than a fortnight away, and twenty four hours for something imminent.
An owner. Somebody has to be chasing. When two administrators share a mailbox, an offer that nobody owns is an offer that nobody follows up.
Those four are exactly the fields a response management tool provides as a matter of course, and exactly the ones a spreadsheet needs a colour convention to fake. This is the real difference between the two approaches, and it has nothing to do with how the form is built. The same structure underlies event and course intake generally, which is why the pattern looks familiar to anyone who has run either.
The two ways a waitlist oversells
Overselling happens in one of two places, and neither is fixed by a better form.
The first is the gap between submission and counting. Two people submit within the same second while the count stands at twenty nine. Both see the confirmation for a confirmed place. A script that counts after the fact cannot prevent this, because the response was already accepted before anything ran. The practical mitigation is to set the closing threshold below the real capacity, treat the last few places as provisional, and confirm them by email rather than by the confirmation screen. Telling people they are registered at the moment of submission is what turns a small counting error into an apology.
The second is treating the spreadsheet as the register. Responses land in a sheet, somebody sorts it, somebody else filters it and forgets to clear the filter, a row is deleted instead of marked as withdrawn, and the count of confirmed attendees now depends on which view is open. Every waitlist disaster that gets described as a form problem is actually this. The form did its job; the list was edited by four people with no history of the edits.
The test is simple. If the question "who has a place" can only be answered by opening a spreadsheet and reading it carefully, the list is not a register yet.
When to stop patching the form
There is a point at which the accumulated workarounds cost more than replacing them. Three signals are reliable.
The first is the second script. One script closing a form on a count is maintainable. A second script sending offer emails, and a third moving rows between tabs, is a small application with no tests and one author.
The second is somebody asking for their position. The moment a waitlist is long enough that people ask where they stand, the list needs a status per person and a way to reply from the same place, because answering it by opening a sheet and counting rows does not scale past a handful of enquiries.
The third is the form running more than once. A single one off event survives anything. A course that intakes every term, or a clinic with a monthly list, will do this ten times a year, and per intake manual effort multiplies by ten.
For a single free event with a comfortable cap, a Google Form and an attentive organiser is the right answer and nothing here changes that. For a recurring intake with a real cap and a list that people ask about, the difference is best seen rather than argued about, and a working response list takes a few minutes to look at.
What to change first
Stop telling people they are registered on the confirmation screen. Change the confirmation message to say that the submission has been received and that a place will be confirmed by email, then close the form a few places below the real capacity. That one change removes the apology, and it costs nothing. If the list itself needs a position, a status and an offer with an expiry, that is what Halict keeps on each response.
Q1. Can Google Forms stop accepting responses after a set number?
Not on its own. The Forms API exposes only quiz settings and email collection in a form's settings, plus a publish setting that opens or closes the form entirely. Closing at a count therefore has to be done by a person watching the responses, or by an Apps Script trigger that counts submissions and unpublishes the form.
Q2. What is the simplest way to add a waitlist to an existing Google Form?
Rewrite the confirmation message so it says a place will be confirmed by email rather than saying the person is registered, then close the form manually a little below capacity and keep a second form for the overflow. It is not elegant, but it removes the worst outcome, which is people believing they have a place they do not have.
Q3. Does the Apps Script approach need maintenance?
Yes, and the maintenance has an owner. Installable triggers run under the account of the person who created them, and other accounts cannot see those triggers, so the automation stops working when that person's account does. The quotas also bind: 100 email recipients per day on a consumer account against 1,500 on a Workspace account, and 90 minutes of total trigger runtime per day against 6 hours.
Q4. How should places be offered to people on the waiting list?
One at a time, in a defined order, with a deadline stated in the offer. Send to the person at the top, give them a fixed window such as three days, and move on if the window passes. Offering a single place to the whole list produces either a race or, more often, several people who each think the place is theirs.
Q5. Should the waitlist be a separate form or part of the main one?
One form with a status per response is easier to run, because positions, offers and replies all sit on one list. A separate waitlist form is easier to set up and creates a reconciliation job that lasts as long as the event does, since neither list knows about the other.