The failure is familiar enough to be a genre. A large upload runs for twenty minutes, reaches the high nineties, and dies. You start again from zero, and it dies again somewhere else.
This is not bad luck, and it is not your connection being uniquely bad. It is a structural property of how naive uploads work.
What actually goes wrong
A naive upload is one long HTTP request. The file streams from your machine to a server in a single connection, and that connection must survive the entire transfer.
Over twenty minutes, plenty can end it:
- A laptop sleeping, or a lid closing
- Wi-Fi handing over between access points
- A phone switching between mobile data and Wi-Fi
- A proxy, load balancer or CDN enforcing a request timeout
- A brief packet-loss burst that stalls the socket past its keepalive
- A DHCP lease renewal changing your local address
- A VPN reconnecting
None of these are exotic. They are ordinary conditions on ordinary networks. And the probability that none of them occurs falls as the transfer gets longer - which is why small uploads feel reliable and large ones feel cursed. The per-minute risk is identical; the exposure is not.
Chunking changes the unit of failure
Resumable uploads split the file into chunks - typically 5 to 100 MB - and upload each as a separate request. The server tracks which chunks have arrived and assembles them once all are present.
The important consequence is that failure becomes cheap. A failed chunk is retried alone. A dropped connection at 96% costs you one chunk, not twenty minutes.
Three further benefits follow from the same design:
Interruptions become survivable. Because the server holds the state of which chunks exist, the upload can pause when you close the laptop and continue when you open it, potentially on a different network entirely.
Parallelism becomes possible. Chunks can go up several at a time, which usually makes the whole transfer faster as well as more reliable - a single TCP connection frequently cannot saturate a fast link on its own.
Integrity becomes checkable. Each chunk can carry a checksum, so corruption is caught per chunk rather than discovered when the assembled file will not open.
This is the same mechanism as S3’s multipart upload, and it is why every serious file tool converges on it - our protocol comparison covers where multipart sits in the wider picture.
Why the last percent is where things die
There is a reason failures cluster near the end, and none of it is superstition.
Accumulated exposure. The longer a transfer has run, the more chances it has had to meet a problem. Failures therefore naturally concentrate at higher percentages, in the same way that most of a long journey’s delays happen after you have already travelled a long way.
Progress bars lie slightly. Many show bytes handed to the operating system rather than bytes acknowledged by the server. The display reaches 100% while a socket buffer is still draining, so the visible failure point is later than the actual one.
Real work happens at the end. Assembly, checksum verification and finalisation occur after the last byte arrives. An error there surfaces at 100%, which feels absurd and is entirely logical.
What to do about a failing upload
Use a client that resumes. If a transfer is large enough to worry about, this is the whole answer. Our uploads are chunked and resumable, so a dropped connection costs a chunk rather than the session.
Prefer a wired connection for very large files. Wi-Fi roaming is a common, invisible cause, and it is especially common in offices and studios with more than one access point.
Check your remaining space first. An upload that would exceed your plan fails for a reason no amount of retrying will fix, and the error is not always explicit about which problem you have. Free here is 5 GB of total storage; our sizing guide covers the arithmetic.
Stop the machine sleeping. On macOS, caffeinate -i for the duration. On
Windows, temporarily set the power plan to never sleep. Obvious once stated, and
responsible for a surprising share of overnight failures.
Move the transfer off your machine entirely. If the source is already reachable by URL, having the server fetch it directly removes your connection from the equation - no laptop to keep open, no home upload speed to wait on, no sleeping to prevent.
When the problem is not the upload
Two cases masquerade as upload failures.
Many small files. A folder of 20,000 small files is slow because of the number of operations, not the volume of data. Archiving first turns 20,000 round trips into one transfer, and is worth doing even when the archive saves no space - the reasoning is the same as for WebDAV.
A slow origin. If you are uploading from a home connection with 10 Mbit upstream, a 40 GB video takes about nine hours no matter how well the protocol handles failure. Resumability makes that survivable rather than fast, and the file-size arithmetic is worth doing before you start rather than after.
The wider point
Reliability at size is not primarily about a faster connection. It is about making failure cheap enough that it stops mattering - so that the question changes from “will this succeed” to “how long will it take”. That is the whole idea behind chunked, resumable transfer.
