Elementor form not working: which step fails

A visitor presses Send and one of three things happens. The first is a validation message on a field that looks fine, often a phone number typed with spaces, or a required field inside a section a toggle hid. The second is a spinner that never stops, which usually means the request failed, because a cached page held an expired security token or a plugin refused the post. The third is a success message with no submission on your side, because a step after the send, such as a notification email, failed or never ran. The visitor sees the first two as trouble. The third looks like success.

• Required fields inside a section that a dropdown or toggle hides from view.
• Phone and email fields that reject formats people actually type, such as spaces or a plus sign.
• The submit request in the browser's network panel: a 403 or 500 points at the server, not the form.
• A success message with no matching entry in your submissions list or your inbox.
• A second visit that behaves differently from the first, which often means a cached copy of the page.

The visitor's experience runs in order. They fill in the fields from top to bottom and press Send. If a field is invalid, the error usually appears under that field, and on a phone the browser scrolls there, which can look like nothing happened if the field sits in a part they did not read. Conditional fields add another trap: a field that appears after an earlier answer and stays required blocks the send with no reason the visitor can see. Check this first, because it needs no server work. Fill the form on a phone with the most common answers and watch for a field you did not expect.

The silent failures cost the most time. A request that never finishes, or a 403 response, comes from the site's side: a cache serving a page with an expired token, a security plugin blocking the post, or an error in a later step. The visitor sees the same spinner in each case. Open the browser's network panel, submit the form yourself, and read the status of the request. A 403 or 500 points at the server or a plugin. A 200 with an error inside the response points back at the form's own settings.

You can separate the causes without touching the server. Open the page in a private window, once on a phone and once on a laptop, and submit with plain answers. If it fails only on the phone, look at the validation and the phone field first. If it fails on the first visit but works after a hard refresh, a cached copy of the form is likely the cause, which is common on sites that cache whole pages.

The success-message case is the one you cannot see from the visitor's side. Check the submissions list in the WordPress admin if the form saves submissions, then the inbox the notification is meant to reach. If the list has the entry and the email did not come, the fault is the email step, not the form. If the list has no entry, the request never reached the server, or the form does not save submissions, so check that setting before you change any field.

A simulated visitor fills the form the way a stranger does, types a phone number the way a person would, and presses Send. The run stops where the visitor gets stuck and records the message on screen, plus failed requests and JavaScript errors from that step. You get the screenshot, the field and the request together. The result is a record a coding agent can act on, not a guess about the form.

Keep a phone visitor in every run. Autofill and the phone keyboard can put a different value into a field than a laptop does, so a form that passes on your laptop can fail for a visitor on a phone. Use the same visitor in each run so the two results compare fairly. The run does not read your submissions list or your inbox, so those checks stay with you.

Run a landing page with simulated visitors

Forms break after changes nobody files under form changes: a caching rule, a theme update, a new security plugin, or a field added for a campaign. Rerun the same visitors after each fix so the next change is compared with a known result. Run the form on each preview deploy before it reaches the live address, and keep one phone visitor in every set, since phones are where the validation and sticky header problems show up.