Batch processing 10 documents from the dashboard

title: "Batch processing 10 documents from the dashboard" description: "How the queue works under the hood, what to expect, and how to recover from partial failures." date: "2026-05-13" tag: "Guide" author: "Inksong"

Inksong supports queueing up to 10 documents at a time from the dashboard. It's the right tool for content teams sprinting on a batch of blog drafts, researchers processing chapter sections from a longer manuscript, translators feeding through a backlog of English-output documents, and anyone else who'd rather walk away and come back to a finished set than babysit a single-file workflow.

This guide covers the mechanics: how the queue actually works, what timing to expect, what happens when one of the ten jobs fails, and how to think about the quota math.

What "batch" actually is

A batch isn't a single grouped operation. It's ten independent jobs that share an upload action — that's the only thing tying them together at the platform level. Once you submit, the worker pool picks them up as parallel jobs, each with its own status, its own result file, and its own potential failure mode.

Under the hood, every job lands in an ARQ Redis-backed queue, gets claimed by an available worker, and runs through the same humanization pipeline as a single-file upload. The worker pool is sized to handle multiple concurrent jobs, so most of your batch will run in parallel rather than serially.

The practical implication: one failed job doesn't take down the others. If document 7 is a corrupt PDF, documents 1–6 and 8–10 still complete normally. You only have to re-run the one that failed. This is different from a "batch endpoint" model where the whole batch fails together, and it's a deliberate design choice.

Step-by-step from the dashboard

Navigate to /dashboard in your browser. Sign in if you aren't already.
Click Upload. A dialog opens with two tabs: single-file and multi-file. Switch to the multi-file tab.
Drag and drop up to 10 files into the drop zone, or click to open a file picker and select them. Supported formats: DOCX, PDF, TXT, MD. You can mix formats in a single batch — five DOCX, three Markdown, two PDFs is fine. The UI shows each file as a row with name, size, and a remove button if you change your mind.
Pick settings. Tone, domain, humanness, and (optional) voice profile apply to all 10 documents in the batch. This is the main constraint of the dashboard batch flow — you can't set different settings per document from a single submission. If you need per-document settings, run them as separate single uploads, or use the API.
Submit. The dashboard packages the files and sends them as a single upload action. You'll see a brief progress indicator while the files transfer.
Page redirects to /dashboard with the documents list showing all 10 entries. Each starts with a pending status indicator and transitions through processing to completed (or failed) independently.

What you'll see while it runs

Each job moves through three states: pending (waiting for a worker), processing (worker is actively humanizing), and completed or failed (terminal). The dashboard polls the backend every 2 seconds, so status updates feel close to real-time without being a true stream.

Timing varies by document length and worker load. A useful baseline:

Single 1,500-word document: 25–60 seconds end to end.
Batch of 10 documents at typical length: 1–3 minutes if the worker pool is unloaded, up to 5–7 minutes during high-traffic periods when other users have queued ahead of you. Most batches finish under 4 minutes.
Worst case for a single document at the per-doc word cap (5,000 on Pro, 10,000 on Enterprise): can stretch to 2–3 minutes for one file. Batches with several large files near the cap will compound.

You can leave the tab. Jobs continue regardless of whether the dashboard is open. When you come back, the documents list shows the current state of each.

Recovering from failures

When a job fails, the row in the documents list shows a failed status with a short error message. Click the row to see the specific error for that job. The most common failure modes:

Corrupt PDF or extraction failure. PDFs are the highest-failure-rate format because PDF is a presentation format, not a content format. Scanned-image PDFs, PDFs with unusual font encodings, and PDFs exported from design tools can all fail extraction. Recovery: re-export the source as DOCX from the original tool (Word, Pages, Google Docs, LaTeX → DOCX via Pandoc), and re-upload.
Document over the per-doc word cap. 5,000 words on Pro, 10,000 on Enterprise. Documents over the cap reject at upload, not mid-processing — you'll see the error before the job enters the queue. Recovery: split the document at natural boundaries (chapter, section, major heading), upload each chunk separately, and rejoin after.
Unsupported file type. Only DOCX, PDF, TXT, and MD are accepted. RTF, ODT, HTML, EPUB will reject. Recovery: convert to DOCX (any modern word processor exports this).
Password-protected files. The extractor can't read encrypted files. Recovery: remove the password from the source and re-upload.
Network or transient errors. Rare, but possible. Recovery: just retry. Re-uploading counts as a fresh job and consumes one quota credit.

You don't get a refund for failed jobs that consumed quota — uploads count toward the monthly cap whether or not humanization succeeded. The exception is documents rejected at validation (over word cap, unsupported format), which don't enter the queue and don't count.

Quota math

A batch of 10 documents consumes 10 quota credits, one per file.

Free tier (5 docs/month): can do half a batch. You'll hit the quota wall at the 6th file, and the upload action will reject the whole batch rather than partially accept. If you're on Free and want to test the batch flow, queue 5 or fewer.
Pro (100 docs/month): ten batches a month, comfortably. Most individual contributors and small teams sit here.
Enterprise (1,000 docs/month): the right plan for teams running daily batches. A team running one 10-document batch every weekday uses ~220 credits a month; even with retries and one-off documents, you're well within budget.

The monthly quota resets on your billing anniversary, not the first of the calendar month. Annual plans get the same monthly cap, billed up front at a ~22% discount.

What it doesn't do (yet)

A few things to be aware of — they're on the roadmap, not currently shipped:

No cross-document state. You can't tell Inksong "humanize all 10 to match each other's voice." Each document is humanized independently. If you need cross-document voice consistency, the workaround today is to train a single voice profile and apply it to every document in the batch — the profile holds voice, even though the humanization runs are independent.
Voice profiles apply per-document at humanization time. You pick the profile once for the batch (it applies to all 10), but there's no "use document 1's style for document 2" mechanism. Use a pre-trained profile instead.
No batch download as a single zip. Each completed document downloads individually from the documents list. For ten files, that's ten clicks. Scripted download via the API is the workaround if this is a frequent need.

Both of these are tracked. If they're blockers for your workflow, the API path gives you primitives to build around them today.

Wrap

For the API path — programmatic batching beyond 10 at a time, integration with a CMS or queue — see Using the Inksong API in a CMS pipeline.