How to cap the number of responses on a Google Form

There are thirty seats in the room, forty two people have registered, and the form is still open. That is the situation, and it is worth being clear about the cause before reaching for a fix: Google Forms has no setting that closes a form once a number of responses has been reached. Not on the free tier, not on Workspace. The setting people go looking for is not hidden. It does not exist.

What Google Forms does have is a manual switch, a per person limit that does something different, and an open door for scripts and add-ons. This article covers all three routes, the failure mode each one carries, and the point at which capping responses stops being the right problem to solve.

What the settings panel actually offers

Open a form, click Settings, and the response controls are short.

Limit users to one response stops the same person submitting twice. Google's documentation is explicit about the cost: to access and fill out the form, users must sign in to their Google Account. That is a per person control, not a total, and it does nothing about the thirty seats. It also turns away anyone who cannot or will not sign in, which for a public event is a real share of the audience.

Allow people to edit responses lets a respondent go back and change what they submitted. Useful, unrelated to volume.

Publish, and the responder access panel behind it, controls who can reach the form at all. A form that is unpublished cannot be answered. Responder access can also carry an expiration date, which removes access on a day you choose. That is a time based control, and it is the closest thing to an automatic close that ships in the product.

So the native toolkit is: one submission per signed in person, and open or shut. Nothing counts.

There is a separate ceiling further downstream that is worth knowing about even though it will not affect an event with thirty seats. Responses linked to a spreadsheet inherit the Google Sheets limit of 10 million cells. A form with 20 columns reaches that at around 500,000 responses. It is a real wall, just not the one most people are standing at.

Route one: close it by hand

The zero effort option is to watch the response count and unpublish the form when it hits the number. For a small intake with a short window, this is fine and nobody should feel bad about it.

It fails in two specific ways. The first is the gap between the last check and the next one. A form that goes out to a mailing list can take forty submissions in the ninety minutes before somebody looks. The second is that a closed Google Form shows a generic message unless you write a custom one, so the people who arrive late get no explanation and email you instead, which is more work than the form saved.

If you take this route, do two things first. Write the closed form message before you publish, so it is already in place when you flip the switch. And set the responder access expiration date as a backstop, so the form shuts on the deadline even if nobody remembers.

Route two: an add-on from the Workspace Marketplace

Several add-ons exist for exactly this, the best known being formLimiter and the family of similar tools that have grown up beside it. They install onto the form, and they close it when a maximum number of responses is reached, at a set date and time, or when a named cell in the linked spreadsheet holds a particular value. Most let you write the message shown after closing.

This is the right answer for most people who are not going to write code. Installation is a few clicks, the cap is a number in a box, and the form closes without anyone watching it.

Three things to check before relying on one. Look at what permissions the add-on requests, because it will be reading your form and usually your spreadsheet. Check whether it is maintained, since Marketplace listings outlive their authors. And test it with a low cap before the real intake, because an add-on that fails silently fails at the worst moment.

There is also an administrative wrinkle in managed Workspace domains: add-on installation is often restricted, and the allowlist request can take longer than the event you are trying to run.

Route three: a few lines of Apps Script

If you want no third party in the loop, the Forms service in Apps Script exposes everything needed. The Form class has getResponses(), which returns an array of every response, and setAcceptingResponses(enabled), which opens and closes the form. Wire those together on an installable form submit trigger and the cap enforces itself.

const LIMIT = 30;

function onFormSubmitCheckLimit(e) {
  const form = FormApp.getActiveForm();
  const count = form.getResponses().length;
  if (count >= LIMIT) {
    form.setAcceptingResponses(false);
    form.setCustomClosedFormMessage(
      'Registration is now full. Contact the organiser to join the waiting list.'
    );
  }
}

To install it: open the form, choose Apps Script from the three dot menu, paste the function, then add a trigger from the Triggers panel set to run onFormSubmitCheckLimit from the form on form submit. The setLimitOneResponsePerUser(enabled) method is available in the same class if you also want the per person restriction, though it carries the same sign-in requirement as the settings panel version.

The advantages are that nothing leaves your account, the logic is visible, and the cap can be as clever as you like: different limits per option, a count that ignores test submissions, a notification when the threshold is close. The disadvantage is that somebody now owns a script. When the person who wrote it leaves, the next intake runs on code nobody has read.

The count will overshoot, and that is by design

This is the part that surprises people, and it applies to the add-on route and the script route equally.

The trigger runs after the response has been recorded. A submission arrives, it is saved, then the code wakes up, counts, and closes the form. Between the save and the close there is a window, and on a busy form several more submissions can land inside it. A cap of thirty can produce thirty three registrations, and the three people who got in are not obviously distinguishable from the ones who did not.

Apps Script triggers also have execution quotas and are not instant under load. On a form that is receiving a submission every few seconds, which is exactly what happens when a registration link goes out to a list at a set time, the overshoot is not an edge case. It is the normal outcome.

There are two honest ways to handle this. Set the cap a little under the real capacity and treat the overshoot as your margin. Or accept that the last few will need a human decision, and make sure the closed form message tells people how to ask about a waiting list rather than leaving them in silence.

A quick way to see the size of the window on your own form is to look at the timestamps in the response sheet from the last time a link went out to a list. If four responses share the same minute, the overshoot on a capped form would have been at least four. If the submissions are spread over hours, the window barely matters and a simple cap will hold. The answer is already in data you have, and it takes a minute to check.

What does not work is treating the cap as a guarantee. If the number genuinely cannot be exceeded, because the seats are physical or the tickets are paid for, a form that closes after the fact is the wrong mechanism. You need something that reserves the place at the moment of submission.

Often the real problem is not the count

Step back from the cap for a moment, because a fair share of the people searching for this are solving the wrong thing.

If the worry is duplicate registrations from the same person, the per person setting handles it, at the price of a sign-in. If the worry is that one session is full while three others are empty, a single total cap is too blunt and what you want is a limit per option, which is the other thing the add-ons do by removing choices as they fill. If the worry is that you cannot tell who is confirmed and who is on the waiting list, the cap is not the problem at all: the problem is that a spreadsheet row has no state.

That last one is the most common. The form closes, forty two people have registered for thirty seats, and now somebody has to decide who is in, tell the other twelve, and keep track of who has been told. None of that lives in Google Forms. It lives in a spreadsheet with a colour coded column and a separate email thread, and it is where the actual hours go.

Tools that close on a count without any of this

If capping responses is a recurring need rather than a one off, some form tools include it as a setting.

Tally's free plan lists closing a form on a limit or a date among its standard features, which makes it the shortest path if this is the only thing pushing you off Google Forms. Microsoft Forms gives you start and end dates but, like Google, no count based close.

Worth noting that a count cap and a submission quota are different things wearing similar clothes. A quota is what the vendor imposes on your plan and it stops the form whether you wanted it stopped or not. A cap is a decision you made about capacity. Tools that keep responses unlimited on every plan leave the cap where it belongs, as a setting rather than a billing tier.

Handle the overflow, not just the cutoff

Whichever route you take, decide in advance what happens to the people who arrive after the number is reached. A closed form with a custom message and a link to a waiting list form turns a dead end into a second queue you can actually use. A closed form with the default message turns it into email.

And once the registrations are in, the work that follows is not about counting. It is about knowing which of the forty two are confirmed, who told them, and what was said. Seeing how other teams structure that stage, in event and application intake, is usually more useful than another rule on the form itself.

What to change first

If this is a one off, install an add-on, set the cap below your real capacity, and write the closed form message before you publish. If it keeps coming back every intake, move the form to a tool where the limit is a setting and the responses carry a status, and look at Halict alongside the others on that shortlist.

Q1. Does Google Forms have a setting to limit the number of responses?

No. The settings panel offers a per person limit, which stops one signed in user submitting twice, and control over whether the form is published at all. There is no field for a total response count. Capping at a number requires an add-on from the Workspace Marketplace or a short Apps Script.

Q2. Why did the form accept more responses than the limit?

Because the check runs after each response is saved, not before. Between the moment a submission is recorded and the moment the script or add-on closes the form, more submissions can arrive, and on a busy form several will. Set the cap slightly below the real capacity to leave yourself margin.

Q3. Does limiting users to one response require them to sign in?

Yes. Google's documentation states that with the one response setting enabled, users must sign in to their Google Account to access and fill out the form. That is acceptable for an internal audience and turns away a share of any public one, so weigh it against how much duplicate submissions actually cost you.

Q4. Can a Google Form close automatically on a date instead of a count?

Yes. Responder access can be given an expiration date, which removes access on the day you choose. Add-ons extend this with a specific time and timezone, and most let you combine a date and a count so the form closes on whichever comes first.

Q5. What is the maximum number of responses a Google Form can hold?

Google does not publish a cap on the form itself. The practical ceiling comes from the linked spreadsheet, which is limited to 10 million cells, so a form with twenty columns reaches it somewhere near 500,000 responses. For ordinary registrations and applications this is never the binding limit.