A submission that shows as "Failed" did not reach your upload destination. In most cases the files are still there and a retry delivers them, so a failed submission is usually a few minutes of work rather than a lost upload. This page covers how to find the failure, read what caused it, fix the cause, and retry. Everything on this page is available on all plans.
Every upload form keeps its own record on the Submissions tab, and the "Status" column there shows how far each submission got on its way to your upload destination.
The "Status" column describes how far a submission got on its way to your upload destination.
Click the chevron at the left of a failed submission to expand it. A red banner sits at the top of the expanded row, headed "File couldn't be delivered", or naming the number of files where more than one failed. Beneath the heading it reads "The destination rejected the upload. Try again, or fix the issue and retry."
Click Technical details in that banner to see the exact reason recorded for the transfer. That line tells you which fix below applies, so read it before retrying.
There are two controls and they do the same thing.
The submission moves back to "Transferring" and a "Transfer restarted" message appears. If the cause is still there it fails again with a new reason, so work out the cause first wherever the reason gives you something to act on.
Retrying needs edit access to the form. A teammate with view access can see the control but gets an error when they use it. See Set form permissions.
A retry does not count against your team's monthly upload allowance a second time. See How bandwidth works.
A transfer that fails for a reason that might clear by itself is retried automatically, five more times, before it is left for you. The gaps between attempts grow: one minute, then five minutes, then fifteen minutes, then an hour, then six hours. A destination that was briefly unreachable usually clears in the first attempt or two without you doing anything.
Two kinds of failure are never retried automatically, because repeating them cannot help. A cloud account that needs reconnecting is one. A destination folder that has been moved, renamed, or deleted is the other. Both go to "Failed" immediately and wait for you.
Notify on transfer failure is on by default on every form, and it emails you once a submission has failed for good, whether it failed immediately or after all five automatic attempts. The subject begins "Action needed:" and names the upload destination.
The form owner is always emailed. Add anyone else in the To row of that notification, on the form's Notifications tab. One email is sent per failure rather than one per attempt, and a submission that fails again after a retry sends a new one. See Set up email notifications.
A submission that has been "Transferring" for more than fifteen minutes is flagged in its expanded row as "Transfer appears stuck", with a Retry Transfer button beside it. Click it to start the delivery again.
These are the reasons the failure banner gives, and what each one means.
Most failures that will not clear on their own come back to the connection. A cloud account can stop working because its access was revoked at the provider, because a password change ended it, or because the account was removed.
Reconnecting retries the submissions that failed on that account automatically. You do not have to go back and retry them one at a time.
FTP and SFTP connections work differently, because they hold the server details you entered rather than a sign in with a provider. The menu item on those reads Edit, and you correct the address, user name, or password in the dialog it opens.
EZ File Drop also emails you about a connection that has been failing, so a form that has quietly stopped delivering does not go unnoticed.
A folder that has been moved, renamed, or deleted in your cloud storage cannot receive files, and the transfer fails without being retried. Set the destination again on the form, then retry the failed submissions.
A form with more than one File Upload field has a destination for each one, so check them all.
EZ File Drop does not keep your files. A file that has been delivered is removed about an hour after your cloud storage confirms it arrived, and any file is removed after 30 days whether it was delivered or not.
Those 30 days are your window. While the files are still there, a retry can deliver them. Once they are gone, retrying cannot bring them back and the person who uploaded has to submit again.
EZ File Drop emails you seven days before that happens, with a subject that begins "Action needed:" and names the form. That email is your last chance to act on the submission.
From that same point, a recovery panel headed "Recover files" appears on the expanded submission, so you can download the files by hand and put them where they belong yourself. It shows for the person who owns the cloud connection the form delivers to, and only after a retry has already been tried at least once.
An upload that never reached EZ File Drop is a different problem from a delivery that failed, and it does not appear on the Submissions tab as a failure. Ask the person what they saw.
On a free trial there is one more possibility. A trial has a hard upload allowance, and once it is used up, anyone opening one of that team's forms sees "This form's account has reached its trial bandwidth limit. The owner needs to upgrade to a paid plan before more files can be uploaded." Choosing a plan lifts the block. Forms on a paid plan are never blocked this way. See How bandwidth works.
Sending it this way saves you gathering the details, and it identifies the exact transfer to look at.