Failed uploads: retry or discard

Every document you upload, forward, or connect flows through Verinode's ingestion pipeline before it ever becomes a job, a vendor record, or a margin figure. Most of the time that happens quietly i…

8 min read·Updated July 13, 2026
On this page

What Failed uploads is

Every document you upload, forward, or connect flows through Verinode's ingestion pipeline before it ever becomes a job, a vendor record, or a margin figure. Most of the time that happens quietly in the background. Occasionally a document cannot be processed: the file is corrupted, the AI extraction step trips on it, a rate limit gets hit, or the data that comes out fails validation. Verinode does not give up after one bad attempt. It retries automatically, with a growing wait between attempts, and only when it has tried three times and still failed does the document stop retrying on its own.

Failed uploads is the page that holds those documents. It is not a dead end: every item there is either fixable (retry it, sometimes after you address whatever tripped it up) or safe to remove (discard it). Nothing is silently lost, and nothing sits unprocessed without you being able to see why.

Where to find it

Failed uploads lives at /data/failed. It is not a permanent row in the sidebar; you land on it three ways:

  • The upload tray. Click the ingestion progress icon (the small upload/activity indicator in the top bar). Any recent failure appears in the tray under an "in progress" section if something is still running. Clicking a failed entry takes you straight to /data/failed.
  • A notification. When a document exhausts its retries, Verinode sends a notification with an "Open Failed Uploads" button that links here directly.
  • The Vault badge. Under My Data in the sidebar, the Vault row (/data) carries a small number badge that combines documents waiting in your review queue with documents that have failed outright. While the My Data section is collapsed, that same combined count rolls up onto the section header itself, so you never lose sight of it just because the section is folded shut.

Failed uploads is a sibling to the review queue: the review queue holds documents that processed successfully but need you to confirm an uncertain match; Failed uploads holds documents that did not process at all.

Why a document ends up here

Every document you send in, whether through file upload, email forwarding, a connected mailbox, a shared folder, a bulk import, a pasted note, or a voice capture, becomes a row in Verinode's ingestion queue. A background process checks that queue roughly every couple of minutes and works through whatever is waiting.

If an attempt fails, Verinode does not mark it dead immediately. It waits and tries again:

  • After the first failure, it waits about 30 minutes before trying a second time.
  • After the second failure, it waits about 90 minutes before a third and final attempt.
  • If the third attempt also fails, the document stops retrying on its own and appears on this page.

That is the "retry limit" the page's own subhead refers to: "Documents that hit the retry limit during processing. Retry sends them through the pipeline again. Discard removes them permanently." A document showing up here has already been given three real chances before you ever have to look at it.

Note

A document does not need to be broken to land here. Rate limits, a slow storage read, or a transient AI provider error can all trip an attempt. That is exactly why Verinode retries automatically before asking you to step in, and why Retry is often all a failed item needs.

Every element on the page

Page header. "Failed uploads" with the subhead described above, always visible whether the list is empty or full.

The list. One row per failed document, most recent failure first, up to 100 at a time. Each row shows:

  • Document label. The filename if one exists, otherwise the email subject line, otherwise "Untitled document" when Verinode has neither (this happens with sources like pasted text or voice captures that never had a file name to begin with).
  • Source · time · attempts. A single meta line under the label reads, for example, "Email · 2h ago · 3 attempts." The source is humanized from the channel the document came in through (Email, Upload, Photo, Paste, Bulk, Voice, or Shared Folder). The time is relative: "just now" for anything under a minute, then minutes, then hours, then days as the failure ages. The attempt count only appears when it is greater than zero, which in practice means every row here shows it, since a document only reaches this page after multiple failed attempts.
  • The failure reason, in red text under the meta line, up to two lines. This is the actual explanation, and it always has two parts: a short classification of what went wrong, followed by a plain-language next step. Verinode buckets every failure into one of eight categories rather than showing you a raw error stack:

| You'll see | What it means | What to do | |---|---|---| | Processing timed out | The document took too long to process in one pass. | Try again, large or complex documents sometimes need a second pass. | | Rate limit hit | A processing service was temporarily throttled. | Try again in a few minutes. | | Could not parse the document | The file's structure could not be read. | Re-upload the document or convert it to PDF first. | | AI extraction failed | The extraction step itself failed. | Try again, this is often a transient error. | | Could not read the uploaded file | The stored file could not be retrieved. | Re-upload the document. | | The extracted data didn't pass validation | Data came out, but it failed a required check. | Open the document and check for missing dates or amounts. | | Authentication issue | A credential or session problem interrupted processing. | Sign out and back in, then try again. | | Internal processing error | An unclassified internal error occurred. | No action needed from you, engineering has been notified. |

Heads up

Verinode never shows you the raw error text or echoes content back from inside your document. LLM extraction failures sometimes surface fragments of the document itself (a dollar figure, a name, a line item), and that is exactly the kind of thing that should not sit in a shared, team-visible failure log. Every error is classified into one of the categories above before it is ever stored or displayed, so what you see on this page never leaks invoice details or claimant names, even though your whole team can see this list.

Discard and Retry. Every row ends with two buttons:

  • Discard removes the document from the queue permanently. Clicking it asks you to confirm: "Discard this upload? This cannot be undone." Once confirmed, the row and its record of the failure are gone. Use this for documents you do not actually need, duplicates, junk mail that got forwarded by mistake, or a test file.
  • Retry puts the document back at the front of the normal queue. It resets the attempt count to zero and clears the stored error, then picks it up again on the next pass, typically within a couple of minutes. If the underlying cause was transient (a rate limit, a timeout, a momentary AI error) Retry alone is often enough. If the cause was structural (an unreadable file, bad formatting) fix it first: convert the file to PDF, re-upload it under Upload, or re-forward the email, then discard the old failed row so you are not tracking the same document twice.

Both buttons show a loading state while the action runs and disable the other button so you cannot fire off a discard and a retry on the same row at once. If either action fails outright (a network hiccup, a permissions issue) a short error message appears under the buttons and you can try again.

Empty state

When there is nothing to review, the page reads: "Nothing here. Failed uploads appear after Verinode has tried three times and given up." Below that is a Back to Vault link to /data. An empty Failed uploads page is a good sign: it means every document you have sent in has either processed successfully or is still working its way through retries.

What happens if you do nothing

A document you neither retry nor discard is not lost or silently deleted. Verinode keeps failed documents on file for about a year so you have a long window to notice and act, after which they roll off automatically along with other terminal, audit-only ingestion records. There is no benefit to leaving one sitting here: retrying costs nothing but a click, and discarding a genuinely unneeded document keeps the list meaningful for the ones that still need a decision.

  1. 1Open Failed uploads from the notification, the upload tray, or the Vault badge under My Data.
  2. 2Read the red reason line under each document, it tells you exactly what went wrong and what to try.
  3. 3If the cause looks transient (timed out, rate limited, a passing AI error), click Retry. It goes back into the normal queue with a clean slate.
  4. 4If the cause is structural (could not parse, could not read the file), fix the file first, convert to PDF or re-export it, re-send it through Upload or email, then Discard the old failed row.
  5. 5If the document was never needed (duplicate, spam, a test), click Discard and confirm.

Data sources

  1. 1.Your uploaded, forwarded, and connected documents. Your business.
  2. 2.Verinode's ingestion pipeline (extraction, validation, and retry logic). Verinode processing.
Was this helpful?