Why did my bulk CV upload stall at 60%?
A batch that freezes partway through is almost always a parsing block, not a lost upload. The files are already in storage — what has stopped is the extraction stage that turns each document into structured fields. Progress is reported per parsed file, so the counter halts even though nothing has been dropped.
The three causes, in order of frequency
Scanned PDFs with no text layer account for roughly seven in ten stalls. Our OCR fallback runs at a fraction of the speed of native text extraction, and a batch containing more than about 200 scanned pages will appear frozen while it works through them. Password-protected files are second: the parser cannot open them, retries three times, and holds the queue slot while it does. Third, and rarest, is a single corrupt archive — a ZIP whose central directory is damaged will block every file behind it in the same shard.
Check this first
Open Batch detail → Skipped files. If the count there is climbing, the batch is working normally and only the progress bar is misleading. If it is static and the timestamp is more than ten minutes old, the queue is genuinely blocked.
Unblocking a stalled batch
Use Resume from checkpoint rather than re-uploading. It restarts extraction at the last committed file and leaves the already-parsed records, along with any ranking work, intact. Re-uploading the same set creates a second batch, and duplicate candidate records then have to be merged by hand.
If the resume fails twice, split the source into sets of 2,000 and upload them separately. This isolates the offending file to one set, and the batch detail view will name it.
Preventing it on the next run
Turn on Pre-flight validation under Sourcing settings. It scans the batch before processing starts and reports unreadable, encrypted and oversized files up front, so you fix the source rather than the run. On Enterprise, pre-flight also raises the OCR concurrency limit for the batch it validated.