An FTP batch that dies halfway almost always fails in one of five places: the control connection timed out while data was still moving, one badly named or oversized file broke the queue, the agency's own processing step never ran, the client opened too many parallel connections, or the files arrived and you were watching the wrong screen. Only the first of those is really a network fault.
The five places an FTP batch actually dies
1. The control connection timed out while data was still moving
FTP is unusual among file transfer protocols in using two connections at once: a control connection carrying the commands, and a separate data connection carrying the bytes. They time out independently, and that is the mechanism behind most silent stalls. IBM's documentation on FTP timeouts during data transfer walks through exactly this case: during a long transfer the data connection completes its work, but the control connection can still be timed out, so the local TCP stack sends keepalive packets to hold it open. Once a keepalive goes unanswered, the local stack assumes the peer has dropped the connection and closes its own side — and it does so without sending a reset.
That last detail explains the symptom. No reset means no error for your client to surface, so the session does not fail so much as go quiet. A file can be fully written on the server with the acknowledgement never getting back to you, which is why the halfway point in your log is not reliable evidence of the halfway point on the server. IBM's guidance on the client side is to leave the transfer timers at their defaults or higher and to set the keepalive option to 60 seconds or greater, and the diagnostic markers it names — a large delta time, a reset, a zero window, out-of-order data, unanswered keepalives — are the same things to look for in any packet capture, mainframe or not.
2. One file in the batch is not acceptable to the server
A batch is only as reliable as its worst file, and a client configured to abort on the first error will stop there. The naming rules are stricter than people expect: Shutterstock's own FTP tutorial states that file names should include only letters, numbers, periods and underscores, and that spaces and special characters are not supported. A single filename carrying an accent, an ampersand or a space is enough to stop a queue that was otherwise fine.
Technical requirements catch the rest. Adobe states a minimum of 4MP for photos, and Shutterstock's help centre is explicit that if requirements are not met the upload will not complete successfully. Canva's submission guidance adds two rules that bite on re-sends rather than first attempts: use unique file names so that new files do not overwrite earlier ones, and do not send compressed files, because archives are not accepted and need unzipping first. A batch that stalls at the same position twice is usually telling you about a file, not a network.
3. The transfer finished and the agency's processing step never ran
This is the case most often misdiagnosed as a failed upload, because the thing you are looking at — an empty portfolio — looks identical either way. Shutterstock's FTP tutorial says it can take up to an hour for its servers to process uploaded files for editing, and its help centre on why content cannot be submitted or uploaded states that FTP uploads can take up to 72 hours to appear on the site. Inside those windows there is nothing to diagnose.
When the window has passed and the files still have not been picked up, Shutterstock publishes an actual remedy rather than a generic retry: set Automatic FTP Processing to No in your account, re-upload, then log in to the submit site and process the files when prompted. That turns an automatic step you cannot see into a manual one you can, which is the right move when the invisible step is the one failing.
4. The client opened too many parallel connections
Most desktop FTP clients default to several simultaneous transfers, which is useful on a fast link to a tolerant server and counterproductive here. The signature is distinctive: the first few files land cleanly, then the remainder fail in a cluster rather than one at a time. Something along the path — the server, a NAT device, a home router with a modest session table — is cutting the extra sessions, and the client reports that as a series of transfer failures rather than as a limit being hit. Neither Shutterstock's nor Adobe's public guidance states a connection limit, so there is no published figure to tune toward. That absence is itself the argument for dropping to one or two connections and letting the batch take longer.
5. The account, not the connection, is what is blocking you
Two account states stop uploads in ways that look technical. Shutterstock's help centre notes that if you cannot upload and cannot log in, the account may be disabled or blocked, and uploads stay unavailable until that is resolved. The second is easier to miss because it is a deadline rather than an event: an overdue tax form disables the Upload and Submit buttons, and the clock is 90 days from the first reminder in the Contributor Portal, with access returning once the form is submitted and approved. Neither will show up in a packet capture, so they are worth ruling out before reaching for one.
Six steps before you re-send anything
A six-step diagnosis for a stalled FTP batch, in the order that avoids creating duplicates: read the client log rather than the folder, count what landed on the server, isolate the file it stopped on against the agencies' stated naming and technical rules, drop to one connection with keepalive at 60 seconds or more, wait out the agency's stated processing window of up to an hour and up to 72 hours, then resume by difference rather than re-sending the batch.
What each agency says happens after the bytes land
Part of what makes a stalled batch hard to read is that the agencies document the post-transfer stage very unevenly. Shutterstock publishes specific windows and a specific remedy; Adobe describes what the portal shows after an interrupted upload but no timings; Canva's submission guidance covers naming and metadata and says nothing about transfer behaviour at all. Knowing which gaps are real gaps, rather than assuming a shared standard, saves a lot of guesswork.
What each agency documents about post-transfer handling
Side-by-side of what Shutterstock, Adobe Stock and Canva each state about the stage after an FTP transfer completes: the processing wait, the appears-on-site window, what happens to an interrupted upload, and the file-name rule. Shutterstock cites up to an hour to process and up to 72 hours to appear; Adobe says the portal shows what uploaded successfully so you can continue with the rest; Canva documents unique file names and no compressed files.
The tools people use for this, and what each is actually good at
FileZilla
Named by Shutterstock's own tutorial as the Windows client to use, which makes it the safest default when you want your setup to match the agency's documentation. Its strength for this particular problem is the transfer queue: failed items stay visible and selectable, so resuming by difference is a built-in operation rather than a scripting exercise. Its weakness is that the defaults are tuned for general use — multiple simultaneous transfers and a modest timeout — so it is one of the clients most likely to produce the clustered-failure pattern until you turn the concurrency down.
Cyberduck
The Mac client Shutterstock names alongside FileZilla. It is the more pleasant of the two to live in, and it handles bookmarked connections to several agencies well, which matters if you are sending the same batch to multiple destinations. For diagnosis it is a little thinner: the logging is less detailed than FileZilla's, so for a stall you are trying to characterise rather than simply retry, you may end up reaching for something more verbose.
A command-line client such as lftp or curl
This is the honest answer for anyone whose batches stall often enough to be a workflow rather than an incident. A command-line client gives you explicit control over concurrency, keepalive and retry behaviour, and it makes resuming by difference a one-line mirror operation instead of a manual comparison. It also logs verbosely enough to tell a timeout from a refusal. The cost is obvious: there is no queue to look at, nothing is discoverable, and a mistyped flag can do real damage to a remote directory. It suits people who want the transfer to be scriptable and are willing to own it.
The agency's own web uploader
Worth taking more seriously than FTP purists usually do, because it removes the entire class of problem described in this article: there is no control connection to lose and no processing step to trigger separately. Adobe's documented behaviour on a dropped connection — the portal shows what uploaded successfully and you continue with the rest — is exactly the resume-by-difference logic you would otherwise build yourself. The limits are volume and attention: it is a poor fit for nightly batches of hundreds of files, and Shutterstock notes that upload problems are sometimes browser-specific, which adds a variable FTP does not have.
Rastock AI
Built for the multi-destination version of this problem rather than for a single stalled session. It writes metadata against each agency's rules and delivers over FTP or SFTP to 10+ agencies, with per-agency delivery status so a partial batch shows up as a status rather than as an absence you have to investigate. It does not take a revenue share, does not claim ownership of your files, and leaves IPTC and CSV export open. Where it is the wrong tool: if you are diagnosing one broken connection to one agency, a client you can watch packet by packet will tell you more. Its case is the repeat delivery rather than the forensic session — see the features page for what that covers.
When to use which
- A one-off stall on an otherwise reliable setup: stay in FileZilla or Cyberduck, drop to one connection, and resume from the queue.
- A stall you need to characterise rather than retry: a command-line client, because you need the verbose log and explicit timers.
- Fewer than about fifty files and no appetite for any of this: the agency's web uploader, where the resume logic is already handled for you.
- The same batch going to several agencies on a schedule: a delivery layer that reports per-agency status, so a stall is visible without a manual audit of each destination.
- An empty portfolio with no error anywhere: none of the above yet — wait out the stated processing window first, then use the agency's documented remedy.
A standing check worth building in
Most of the pain in a stalled batch comes from not knowing what landed, so the check worth automating is a remote listing taken after every run and diffed against the local batch. That one habit converts every future stall from an investigation into a short list of missing names. If you are setting a connection up from scratch, our walkthrough of how to upload to Shutterstock via FTP covers the configuration side, and the duplicate risk that re-sending creates is handled in more depth in our guide to avoiding duplicate uploads across agencies.
If the batches are large and nightly, the question stops being how to diagnose a stall and becomes which delivery setup fails visibly — something we looked at separately in reliable tools for large nightly FTP batches. Rastock AI's pricing includes a 14-day free trial with no card required, which is enough to run a few real batches and see whether per-agency status tells you what your current client does not.
Frequently asked questions
Why does my FTP upload stop halfway with no error message?
The most common technical cause is the control connection timing out while data is still moving. FTP uses two separate connections, and IBM's FTP client documentation describes a long transfer where the data transfer completes but the control connection is timed out, with the local stack closing its side once a keepalive goes unanswered and without sending a reset. No reset means no error for the client to report, which is why the session appears to simply stop.
How long should I wait before assuming an FTP upload failed?
Longer than most people do, because the agency's own processing window comes after the transfer. Shutterstock states it can take up to an hour for its servers to process uploaded files for editing, and that FTP uploads can take up to 72 hours to appear on the site. Waiting out the stated window costs nothing; re-sending inside it is how duplicates get created.
Will re-uploading the batch create duplicates?
It can, and duplicates are a review problem rather than just a tidiness problem. Resume by difference instead: list what is already on the server, compare it against your local batch, and send only the names that are missing. Canva's submission guidance also warns to use unique file names so that new files do not overwrite earlier ones, which cuts the other way on a re-send.
Does file naming really break an FTP batch?
It can stop one, depending on your client's error handling. Shutterstock states file names should include only letters, numbers, periods and underscores, and that spaces and special characters are not supported. A client set to abort on the first error will stop at the first non-conforming name, leaving a batch that looks half-transferred when the actual fault is one file.
How many simultaneous FTP connections should I use?
Fewer than the default. Neither Shutterstock's nor Adobe's public guidance states a connection limit, so there is no published number to aim for, which means the safe setting is one or two concurrent transfers and a longer run time. A cluster of failures after the first few files land is the usual sign that too many parallel sessions are being cut somewhere along the path.
My files uploaded but the agency shows nothing. What now?
Check whether the agency's processing step ran before assuming the transfer failed. Shutterstock publishes a specific remedy for files that arrive but are not processed correctly: set Automatic FTP Processing to No in your account, re-upload, then log in to the submit site and process the files when prompted. Also confirm footage is not simply sitting in the video portfolio rather than the photo one.