Google Forms has an unusual failure style. It does not stop. It keeps accepting answers while quietly withdrawing the screens you used to read them on, and nobody gets an email about it. Somebody notices weeks later that the chart they showed at a monthly meeting is gone, or that the spreadsheet they trusted stopped filling, and then spends an afternoon reconnecting something that was never disconnected.
Knowing the thresholds in advance turns that afternoon into a two minute check. Some of the limitations below are published numbers. Some are not numbers at all, and those are the ones that usually decide whether a team keeps using it.
The thresholds where screens disappear
Google publishes these in its help documentation, framed as an explanation of why features might not work as expected rather than as a limits table. The wording matters: the form continues to receive responses throughout, and a CSV download stays available.
| Responses on one form | What is no longer there |
|---|---|
| More than 10,000 | The question view and the individual response view are not available in Forms. A downloaded CSV is no longer sorted by the timestamp of submission |
| More than 50,000 | The response summary is not available |
| More than 100,000 | Responses are no longer synced with Sheets |
The first row is the one that arrives earliest and costs the most. Past 10,000 responses there is no screen in Google Forms that shows one person's submission on its own. For a survey that is a nuisance. For an application form, a grant intake or a support queue, the individual view is the work, and losing it is not a degradation of reporting but the removal of the main interface.
The CSV detail in the same row causes quiet damage. A team that assumes the export is chronological, and treats the bottom rows as the newest arrivals, will process the wrong entries without any sign that something is off. Sorting by the timestamp column restores the order, and the data itself is intact.
None of these three events produces an error message. Each one is discovered by somebody wondering why a screen looks different from how they remember it, which is usually long after it changed.
The spreadsheet is not a bigger version of the form
Most teams stop reading responses inside Forms very early and work in the linked Google Sheet instead. That moves the problem rather than removing it, and it introduces limitations of its own.
The size ceiling is published under Drive rather than Forms. A spreadsheet created in or converted to Google Sheets holds up to 20 million cells or 100 MB, whichever comes first. Cells, not rows, is the figure to hold on to, because every answer to every question occupies one. A form with 40 columns therefore reaches the cell ceiling at a very different row count than a form with 200.
The permissions behave in a way that surprises people. When the response spreadsheet is created, collaborators on the form automatically get access to it. Google then states plainly that further changes to the permissions of the form will not synchronize automatically, and that access has to be updated on the form and the linked sheet separately. Removing somebody from the form leaves them with the sheet, which contains every response ever submitted.
Two more behaviors are worth knowing before you need them. Unlinking a spreadsheet stops new responses arriving there while leaving the existing data intact, which makes it a usable way to close off a period. And deleting responses inside the form cannot be undone, which makes the delete options in the responses menu worth treating carefully on any form that matters.
What you can actually enforce on an answer
Google Forms has no published character cap on a response, which sounds generous until you need a predictable one. What it has instead is response validation, and the set of rules available is narrower than most people assume.
Google's automation reference documents the full set for text answers. For a short answer question and for a paragraph question alike, a rule can require the response length to be greater than or equal to a number, or less than or equal to a number, and it can require the response to match, contain or not contain a regular expression pattern. Short answer questions add numeric rules on top of that.
Notice what is absent. There is no word count rule. A brief that says "answer in 200 words or fewer" has to be expressed as a character count, or as a regular expression that counts spaces, neither of which is a thing a respondent can see while typing. There is also no per form total, so a form with six paragraph questions has no ceiling on how much text one person can submit across all of them.
Identity is constrained in the same indirect way. Turning on "Limit to 1 response" requires respondents to sign in to a Google Account in order to access and fill out the form, and their usernames are still not recorded unless email collection is turned on separately. For an internal form that costs nothing. For anything public it is a filter, and a proportion of respondents on a work address with another provider, or on a shared device, will simply stop at that point.
Closing a form is newer than it looks
For most of the product's life, stopping a Google Form meant switching off "Accepting responses" by hand, at whatever hour the deadline happened to fall, or installing a third party add on to do it for you. That is why so much of the advice written about closing forms is about add ons.
That changed on January 12, 2026, when Google launched the ability to set a close date and time or a response limit directly. In a published form, the publishing controls now offer a close date or response limit, along with a custom message shown to anyone who arrives afterwards. The feature is off by default and is enabled by the form creator after the form is published, and it is available to Workspace customers, Workspace Individual subscribers and people using personal Google accounts.
Two constraints on it deserve to be read carefully. If the form already has responses, the limit entered has to be greater than the number already received, so it cannot be used to retroactively cap a form that overran. And Google states that if multiple people respond at the exact same time, the form accepts responses regardless of the response limit.
That second sentence is the one to act on. A response limit is a way to close a form approximately on time, not a way to guarantee that exactly 30 places were filled. Anything where the number is a commitment to real people still needs checking after the fact.
There is a related limitation in the publishing model itself. A form has to be published before responders can access it, and Google notes that responses cannot be accepted in an unpublished form. Unpublishing is therefore both the pause button and the off switch, which is fine until two people disagree about what state a form should be in.
Automating your way out has its own ceilings
The usual response to the thresholds above is to stop using the Forms interface and read responses through the API instead. That works, and it is metered.
The Forms API publishes per minute quotas rather than daily ones. Read requests are limited to 975 per minute per project and 390 per minute per user per project. The call that lists responses is classed as an expensive read and gets less: 450 per minute per project and 180 per minute per user per project. Write requests are limited to 375 per minute per project and 150 per minute per user per project. Provided you stay inside the per minute figures, there is no daily cap.
The Sheets API, which is where most automation actually reads from, is considerably tighter: 300 read requests per minute per project and 60 per minute per user per project, with the same figures for writes. A single request that takes longer than 180 seconds to process returns a timeout, and Google recommends keeping a payload under 2 MB.
There is also a change worth planning for if you create forms programmatically. Google states that forms created with the API after June 30, 2026 will have an unpublished state by default, which means a pipeline that creates a form and shares the link will hand out a link that does not accept responses until the form is published.
The limitations that are not numbers
Everything above can be planned around. These cannot, because they are absences rather than thresholds.
A response has no owner. Nothing in Google Forms records which person on the team is handling a given submission. Teams invent the field by adding a column to the linked sheet and typing a name into it, which works until two people type at once, or until somebody sorts the sheet and the names detach from the rows they belonged to.
A response has no status. Nothing distinguishes a submission that arrived this morning from one that was answered three weeks ago and closed. That is a second hand made column, as reliable as everyone's discipline on a busy day.
There is nowhere to reply from. Email notifications for new responses go to the form's editors. Replying means copying an address into a mail client, writing there, and sending from there, after which the record of the reply lives in one person's sent folder where no colleague can see it. This is the ordinary cause of two people answering the same applicant, and of one applicant hearing nothing at all.
These three absences move more teams off Google Forms than any published threshold does. They also explain why the move tends to happen suddenly, since nothing degrades and then one duplicated reply to a real applicant makes the case on its own. A form tool built for the work after submit treats the owner, the status and the reply as part of the response rather than as columns somebody maintains, which is a different product shape rather than a bigger plan.
Working out which limitation you have hit
The symptoms overlap enough that teams regularly fix the wrong thing, so it helps to check in order.
If summaries and charts vanished while the sheet is still filling, the form has passed 50,000 responses. The connection is fine and reconnecting it changes nothing.
If new rows stopped appearing in the sheet, look at the response count first. Above 100,000 responses, that is the answer and relinking will not help. Well below it, check the sheet against the 20 million cell ceiling by multiplying columns by rows.
If an export looks jumbled, that is the 10,000 response threshold changing the sort order, not a corrupted download.
If somebody with access to the sheet should not have it any more, that is the permission behavior rather than a limit, and it has to be fixed on the sheet directly.
And if the complaint is that a form closed late, or took one booking too many, that is the documented behavior of the response limit rather than a fault. Check it against the kind of intake you are running and decide whether approximate is good enough.
What to change first
Find the response count on your busiest form and compare it against the table above, because the 10,000 mark removes the individual response view and most teams cross it without noticing. If the form is comfortably inside every threshold and the real bottleneck is the owner column and the status column somebody maintains by hand, the limitation you have hit is not a number, and the answer is a tool that gives every response an owner, a status and a reply box on one screen, which is what Halict is built around.
Q1. Is there a maximum number of responses a Google Form can accept?
Google publishes no hard cap, and the form keeps collecting. What it publishes are thresholds where features withdraw: above 10,000 responses the question and individual views are not available and CSV downloads stop being sorted by submission time, above 50,000 the response summary goes, and above 100,000 responses are no longer synced with Sheets.
Q2. Why did the linked Google Sheet stop updating?
The most common reason is that the form has passed 100,000 responses, which Google documents as the point where responses stop syncing. The second possibility is the spreadsheet itself reaching its own ceiling of 20 million cells or 100 MB, which a wide form reaches at a much lower row count than a narrow one. Reconnecting the sheet does not help in either case.
Q3. Can a Google Form be limited to a set number of characters?
Not by default, but response validation can enforce it. Google documents rules requiring a response length greater than or equal to, or less than or equal to, a number you choose, for both short answer and paragraph questions, along with regular expression patterns. There is no word count rule and no total limit across the whole form.
Q4. Does the response limit guarantee a form stops at exactly that number?
No. Google states that if multiple people respond at the exact same time, the form accepts responses regardless of the response limit. The limit is reliable enough for a deadline and not reliable enough for a fixed number of seats, so anything with real capacity attached needs to be reconciled afterwards.
Q5. Who can still see responses after being removed from a form?
Anyone who was a collaborator when the response spreadsheet was created keeps access to that spreadsheet, because Google does not synchronize later permission changes from the form to the sheet. Access has to be removed in both places separately, and until it is, the removed person can read every response the form has ever collected.