Bulk checks
Asynchronous jobs that run one check mode across huge domain lists — live streaming results, fair scheduling, and CSV export.
A bulk check is an asynchronous job that runs one check mode across a list of domains — the New Bulk Check dialog puts the ceiling at 500,000 domains per job. You get a job page with a live progress bar, results that stream in as they resolve, filters, and CSV export.
When bulk vs. single
- Single check for interactive questions — "is this one name free?".
- Bulk check for lists: evaluating name-generator output, nightly sweeps of a candidate portfolio, availability triage of a brand's typo space.
How a job runs
- You submit the domains and a mode. Input is normalized and deduplicated before anything runs — you're never charged twice for the same domain in one job.
- The job is created in
processingstate and returns immediately. - Worker processes fan out across the list. Each domain runs the standard mode pipeline (cache first — see cache tolerance — then the mode's sources).
- Results land as they complete. The dashboard job page updates live; the API offers paginated results plus a Server-Sent Events stream that delivers each result the moment it resolves.
- When the last domain resolves, the job flips to
completed.
Job statuses
| Status | Meaning |
|---|---|
processing | Domains are being worked through; the progress bar shows completed/total. |
completed | Every domain resolved. |
cancelled | You cancelled it — resolved results are kept, pending domains never ran. |
failed | The job itself failed (rare — individual domain errors do not fail a job; they appear as per-domain statuses). |
Fair scheduling
Bulk work is scheduled with a per-organization concurrency cap, so one organization's 500k-domain job can't starve everyone else — and your own single checks always jump the queue ahead of your running bulk jobs. Interrupted work self-heals: items stuck mid-processing (a worker restart, say) are automatically re-queued within minutes.
Cache tolerance
Each job sets how old a cached result may be and still count — in the dialog: No cache — always fresh, or up to 1 hour / 24 hours / 3 days / 7 days old.
This is the main cost lever: re-running a 50,000-domain list you checked yesterday with a 3-day tolerance resolves almost entirely from cache. Fresh runs cost full price. Cache hits are marked on each result.
Cancellation
Cancel an in-flight job from the job page (or
POST /check/bulk/{id}/cancel). Already-resolved results are kept and
remain exportable; pending domains are dropped and never run — you pay
only for what ran. Only processing jobs can be cancelled.
Deleting a job
Deleting a bulk check (from the job's ⋯ menu) removes the job and all its results permanently — the confirmation dialog says exactly that. Export the CSV first if you need the data.
Behaviour and edge cases
- Results arrive in resolution order, not input order. If you need to correlate with your source rows, join on the domain afterwards.
- Malformed or unresolvable domains show up in the results with an
errorstatus and message instead of vanishing. - Rate limits apply to job creation, not job size: 60 new bulk jobs per hour per organization, 20 per user. See Limits and errors.
- Estimated cost is shown before you run — the dialog's confirm step breaks down free-tier queries vs. billable ones. "Final cost may vary. Billed at end of month."
Related
- Run a bulk check — the dialog step by step, the results page, and CSV export.
- Check modes — what each mode queries.