By platform
Airtable form not submitting: find the field
The visitor fills in your public Airtable form, presses Submit, and either sees nothing change or finds a message under a field they already scrolled past. Mimiq sends simulated visitors through the same form and shows the field and step where each one stopped.
Why won't my Airtable form submit?
A shared Airtable form saves a row only when every required field has a value that passes that field's format check. When the press fails, the cause is usually one of three things: a required field the visitor missed, a value the field refuses, or a file the attachment field will not take. A simulated test fills the form the way a visitor would and shows which field the press stopped on, with a screenshot of what the visitor saw.
What this looks like in a report
“I typed my email and picked a date, then pressed Submit and the page just sat there. There is a small red line somewhere, but I cannot see where. I will try a different photographer.”
The fix. Mark only the name and email as required, and move the date field above the Submit button. Then press Submit on an empty form on a phone and confirm the first error shows near the button.
An illustration. Run a test to see your own.See a real sample report
The error sits under a field the visitor has already scrolled past
The form checks the answers when the visitor presses Submit. A required field left empty is one kind of failure. The other kind is a value that breaks its format, such as an email address with no at sign, or a file the upload refuses. Either one can show its message near the field that caused it, and on a long form that field can sit far above the button. The visitor has already scrolled down to Submit, so the press looks like it did nothing. They press again, see the same silence, and leave. You only see the rows that got through.
- Submit an empty copy of the form and note every field that shows a message, and whether that field is on screen.
- Compare the required fields in the form view with what a visitor sees on a phone, where some fields sit below the fold.
- Type a valid but unusual address into each email field and confirm the form accepts it.
- Upload a normal-sized file to each attachment field, from a phone, in a private window.
- Open the base and look for a new row. If it is there, the press worked and the message misled the visitor.
Where a visitor meets the error, top to bottom
A visitor meets the form from top to bottom. They type a name, then an email, then pick a date, and then they press Submit. The failure that causes trouble is the one that points at a field they finished long ago. A visitor who has typed a long message does not expect an error at the bottom, or one above the button they have just scrolled past. Format checks are the quiet ones. An email field can refuse an address the visitor is sure is correct, and the form stays where it is with no obvious reason. Nothing sends the visitor to another page, so they assume the form is broken and leave.
Reading the base to see which side failed
Open the base after your own test and look for the test row. If your row arrives and a visitor's does not, look at what the visitor typed and the device they used, since your own values may pass every check. If no row arrives at all, the failure is in the form itself, and the first place to look is the list of required fields in the form view. Check that list on a phone as well, because a field that is easy to skip on a laptop can be the one that blocks a phone visitor who never sees the error.
The message and screenshot a run keeps at Submit
The simulated visitor fills each field it can see, in order, and presses Submit at the end. If a field refuses the value, the run records that field's name and the message it showed, along with a screenshot taken at the press. If the press makes no visible change, the run records that as well, together with any failed request the browser logged at that moment. The run cannot open your base, so it does not know whether a row was created. Pair the report with one look at the base after each fix, and keep the same visitors for the rerun.
Mimiq is independent and not affiliated with the platforms it names. Names belong to their owners.
What you get with Mimiq
- 01
Run it by hand, or on every pull request
Paste a link and a task in the app and watch the visitors work. Or run them on every preview deploy: the GitHub Action comments on the pull request, any other CI can call the MCP endpoint, and your coding agent can run it too.
- 02
Bugs and usability problems in one report
The browser records errors and failed or slow requests on the step they happened. The visitors say where the wording or the steps confused them, and where they left.
- 03
Visitors that behave like your audience
Each visitor is a different profile with a reason to be there, matched to who the page is for, described by you, or built from your own customers.
- 04
A prompt to fix each problem
Every problem comes with a fix to paste into Cursor, Claude Code, Lovable or any coding agent, and one prompt hands over the top problems at once. Then send the same visitors through again.
- 05
Follow every visitor
See each visitor's whole path, step by step with screenshots, and what it was thinking at every step. Ask any visitor a question.
The browser records relevant JavaScript errors and failed or slow app requests encountered during the run, attached to the step where they occurred. The visitors are simulated: they find problems, they do not predict how many real people will convert.
A new required field can silence the form again
Each edit to the form, such as a field added, a field made required or a field moved, can move the failure somewhere new. Rerun the same simulated visitors after every change and check that they reach the confirmation, not just that the form looks right in your own browser. An owner who edits a form every week needs this more than a one-time check.
Starter
Try it on one launch
About 4 tests of 5 visitors
- Visitors on your landing page, signup and checkout
- Where they left and why, with a fix to copy for each problem
- Run it in the app or on every pull request
- Ask any visitor a question, included
- Test accounts and protected previews
Builder
Test every build
About 20 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Pro
Test every release, as a team
About 60 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Scale
Test at scale, every day
About 240 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Priority support
- Cancel anytime
Questions
Why does my own test submit when visitors fail?
Your test runs while you are signed in to the base, and you already know which fields are required. A visitor types different values, may use a phone, and can skip a field that looks optional. Try an empty submit and an email with an unusual format in a private window. That is closer to what a stranger does.
Will the form always show me an error I can read?
No. A message can show beside one field, or the form can look unchanged after the press. A message can also sit near a field far up the form while the press is at the bottom. Scroll the whole form before you decide it stayed silent.
Can an old share link stop showing the form?
Yes, if the owner stops sharing the form. A link in an old email or a post can then lead to a page without the form. Use the link the form shows today in your test, and compare it with the link on your page.
Does the test confirm that my base received the row?
No. The test shows what the visitor saw at Submit, including any message and any failed request the browser logged. Open your base after the run and look for the test row. The test cannot tell you whether the row is complete, or whether a real visitor would have finished the form.
Do I need to test on a phone too?
Yes, when the form is long or public. Simulated visitors use laptop and phone browsers, so you can run the same visitors on both and compare where each one stopped. A required field below the fold is one way a phone visitor ends up with no error on screen at all.
Keep reading
Send visitors and see what breaks first.
Your first test is free: sign in with Google and it starts right away. Last checked 2026-11-02.