The form says forty-one responses. The spreadsheet shows thirty-eight rows. Somebody is waiting on an answer that is in neither place you have looked, and the fastest way to make this worse is to start clicking things.
Work it in order instead. The causes fall into four groups, they are easy to tell apart once you know what separates them, and only one of them is rare.
Step one: find out which number is wrong
Open the form, click Responses, and read the count on the Summary tab. Then open the spreadsheet and count the data rows. The gap between those two numbers tells you which direction to investigate, and it is the only diagnostic that costs nothing.
If the form has more responses than the sheet has rows, the delivery path between them is the problem. That is the link, the destination, or a volume limit, and the next three sections cover it.
If both numbers match, nothing is missing. What you are looking at is a display problem inside the spreadsheet: a filter, a sort, a hidden row, or the wrong tab. That is the most common outcome of this check, and it is a relief, because nothing has to be recovered.
If the sheet has more rows than the form reports, somebody has typed into the sheet by hand, or the form's own responses have been deleted while the rows stayed behind. Both are worth knowing about before you do anything else.
One more thing to confirm at this stage: that you have the right form open. Duplicated forms are a common cause of this entire situation. Someone makes a copy to test a change, the copy gets shared, and half the submissions arrive on a form nobody is watching. A copy has its own response store and its own destination spreadsheet, and from the outside the two forms look identical.
The form is not linked to the sheet you are reading
Linking is not permanent, and it can be undone from a menu that also contains harmless items.
On the Responses Summary tab, the three dot menu at the top right contains Unlink form. Google's description of what happens is precise: new responses will not be sent to the spreadsheet, but your current data remains intact. That is exactly the symptom being investigated. The old rows are still there and perfectly readable, and the new ones stopped arriving, which looks far more like a bug than like a menu item somebody clicked last month.
The same menu contains Select destination for responses, which offers to create a new spreadsheet or to select an existing one. If somebody used that to point the form at a different file, the sheet you have open is a snapshot from before the switch and will never update again.
To check and repair: open the form, Responses, Summary, three dot menu. If the option reads Unlink form, a link exists. If it offers Select destination for responses, there is no link, and choosing a destination will restore the flow. Before creating a new spreadsheet, search Google Drive for existing response sheets with similar names, because the file you want probably already exists and is holding the missing rows.
There is a permissions trap attached to this. Google notes that when you create a new response spreadsheet, form collaborators automatically get access to it, but that further changes to the permissions of the form do not synchronise automatically, so access has to be updated on the form and the linked sheet separately. A colleague who says rows are missing may simply be looking at an older sheet that they still have access to while the current one was never shared with them.
The rows arrived and the spreadsheet is hiding them
If the counts matched in step one, this is where the answer is. Four things hide rows in a sheet that is otherwise working normally.
A filter is on. A filter applied by anybody applies to everybody in a plain filtered range, and a new response that does not match the criteria is invisible the moment it lands. Look for the filter icon in the toolbar and clear it, then count again.
The sheet was sorted by hand. New responses are appended to the bottom of the sheet as they arrive. On a sheet that somebody sorted alphabetically or by a status column, the new arrivals still go to the bottom, which is now the wrong place visually. They are not missing, they are out of sequence, and anybody scanning the middle of the sheet will not see them.
There is more than one tab. Response sheets accumulate tabs: a pivot, a working copy, a tab somebody made for a report. The tab receiving responses is not always the one that opens first.
Rows or columns are hidden. Easy to do accidentally and easy to miss, since a hidden row leaves only a thin line between row numbers.
Before changing any of these, make a copy of the sheet. Restoring a deliberate filter setup that you cleared while troubleshooting is tedious, and version history is easier to use when you know which version was the good one.
A practical habit: work from a separate tab that pulls from the response tab, and leave the response tab alone. Filters, sorts and extra columns on the tab that receives responses are where most of these problems begin.
The volume limits Google publishes
This is the cause almost nobody checks, and unlike the others it is documented with exact numbers. Google states that certain features stop working as forms grow, that these limits exist so Forms works reliably for everyone, and that the form continues to receive responses regardless, which can be downloaded as a CSV file.
| Threshold | What stops working |
|---|---|
| More than 10,000 responses | The question view and individual view for responses in Forms |
| More than 10,000 responses | Timestamp ordering in the downloaded CSV file |
| More than 50,000 responses | The response summary |
| More than 100,000 responses | Syncing responses to Sheets |
The 100,000 line is the one that produces this exact search. Submissions keep arriving, the form keeps accepting them, and the spreadsheet stops growing. Nothing is broken and nothing is lost, but no amount of unlinking and relinking will fix it, because the sync is the thing that has stopped.
If a form is anywhere near these numbers, the response store is being used as a permanent archive. Export the history, close the old form to new responses, and publish a new one with its own destination spreadsheet. Keeping years of intake in a single form costs you the interface long before it costs you the data.
When the rows are present but the cells are empty
A different complaint arrives at the same search: the rows are all there, and the answers are not. Blank cells in the middle of a sheet read as data loss, and they usually are not.
The common cause is that the form changed after responses started arriving. Add a question, and a new column appears for it. Every response submitted before that change has nothing to put in the new column, so those cells stay empty forever, correctly. Rename a question and the column heading may no longer match what people believe they asked. Delete a question and the column holding its answers becomes an orphan.
Optional questions produce the same visual effect for an entirely ordinary reason. A question that is not marked required is one that people skip, and a column of scattered blanks is the accurate record of that.
The check is quick. Pick one blank cell, note its column heading and the timestamp on its row, then look at whether that question existed when that response was submitted. If it did not, nothing is missing. If it did, and the question was optional, nothing is missing either. If it did and the question was required, that is worth investigating properly, and the CSV export is the place to confirm it, because it is generated from the form's own store rather than from the sheet.
There is a working rule underneath this. Treat a form that is already collecting responses as frozen. Changes to questions on a live form are cheap to make and expensive to interpret six weeks later, when the person reading the sheet has no idea the shape of the data changed partway down. If a question genuinely has to change, publish a new form for the new version rather than editing the one holding the history.
Matching the symptom to the cause
| What you see | Most likely cause | Where to look |
|---|---|---|
| Rows stopped on a specific date | Form was unlinked, or the destination was changed | Responses, three dot menu |
| Some responses appear, others never do | A filter, or a hand sorted sheet | The filter icon and the bottom rows |
| Nothing has ever appeared | Form was never linked, or you have a duplicate form | Select destination for responses |
| A colleague sees rows you do not | Two different spreadsheets, or separate permissions | Google Drive, sorted by recent |
| Counts match but the sheet looks short | Hidden rows, or the wrong tab | Row numbers, and the tab bar |
| Form count is very large and growth stopped | A published volume limit | The table above |
Work down the column on the left. Each row takes under a minute to check, and the order is roughly from most to least common.
Why this keeps happening to the same teams
Every cause listed here comes from the same underlying arrangement. The spreadsheet is doing two incompatible jobs at once.
Job one is being a log: an append only record of what arrived, which must not be touched. Job two is being a working surface, where people sort by urgency, filter to their own cases, add a column for who is handling what, and highlight the rows they have dealt with. Every action in the second job endangers the first, and the sheet does not warn anyone, because sorting a spreadsheet is a completely normal thing to do.
Teams that have been through this twice usually reach the same fix without being told: leave the response tab untouched and do the work somewhere else. That works, and it is free. What it does not solve is the reason people were editing the log in the first place, which is that a submission has no owner and no status until a human writes one in a cell. A response list where those two fields exist as part of the record removes the motive entirely, and it is worth seeing what a response looks like when it carries its own status before building a third tab of formulas to compensate.
What to change first
Run the count comparison in step one, because it decides which half of this page applies and takes thirty seconds. Then move your filters, sorts and status columns off the tab that receives responses so the log stays a log, and if the team needs owners and statuses on each submission, put them where they belong rather than in a spreadsheet column, which is what Halict and similar tools exist to do.
Q1. Why did my Google Form responses suddenly stop appearing in the spreadsheet?
The usual cause is that the form was unlinked or its destination was changed. On the Responses Summary tab, open the three dot menu: if it offers Select destination for responses rather than Unlink form, no link is active. Google's own description of unlinking matches the symptom, since existing data remains intact while new responses stop arriving.
Q2. Do old responses appear in the sheet when you link one later?
Linking a destination is how Forms sends responses to Sheets, and the responses themselves are always kept in the form regardless of whether a sheet is connected. If the sheet ends up incomplete after linking, the reliable way to reconcile is to download the full history from the form as a CSV using Download responses on the Responses tab, and compare it against the sheet.
Q3. Is there a limit on how many responses a Google Form can send to Sheets?
Yes, and Google publishes it. Responses stop syncing with Sheets past 100,000 responses on a form. Related thresholds affect other features earlier: the response summary past 50,000, and the individual and question views past 10,000. The form keeps accepting responses in every case, and they can be downloaded as a CSV.
Q4. Why can a colleague see responses that are missing from my copy?
Most often there are two spreadsheets rather than one, with the form now writing to the newer file. Permissions are the other explanation. Google notes that form collaborators get access to a newly created response spreadsheet automatically, but later permission changes on the form do not synchronise, so access has to be updated on both files separately.
Q5. Can deleting rows in the spreadsheet delete responses from the form?
The spreadsheet is a separate file in Google Drive, and Google states that either it or the form can be deleted without the other. Because of that separation, editing one side does not reliably reflect on the other, so check both places after any cleanup and keep a CSV export before deleting anything, since deleting responses in a form cannot be undone.