Guides
for everything Geocodio
Guides
Why spreadsheet uploads get queued
Guides
for everything Geocodio
Why spreadsheet uploads get queued
If you've uploaded several spreadsheets or lists and only one of them seems to be moving, that's expected. Geocodio limits how many of an account's spreadsheets can be processed at the same time, so anything past that limit waits in line and starts automatically once a slot frees up.
This is a deliberate concurrency cap, not a failure. It protects the processing capacity that's shared across all accounts, so one very large batch of jobs can't crowd out everyone else's. Uploads past the limit are never rejected — the upload succeeds immediately, and the extra spreadsheet simply waits in the queue until it's its turn.
How many spreadsheets can process at once
The limit depends on your plan:
| Plan | Concurrent spreadsheets |
|---|---|
| Pay-as-you-go and Flex | 1 at a time |
| Unlimited and Enterprise Unlimited | 3 per dedicated instance |
If your account has more than one instance in its spreadsheet pool, each instance adds another 3 concurrent slots, so your total concurrency scales with the number of instances you have.
Dashboard and API/CLI uploads share the same queue
The limit is per billing account, not per upload method. A spreadsheet you start from the Geocodio dashboard draws from the same pool of processing slots as a list you create through the API or the Geocodio CLI. If you start a dashboard upload and an API list around the same time, they're competing for the same slots — neither one gets priority over the other.
What to do while a spreadsheet is queued
Don't re-upload it
If a spreadsheet has been sitting there for a while, leave it alone. The original upload is still in the queue and will process on its own — uploading it again just creates a second list behind the first one, and you'll be billed for every lookup a second time once it runs.
Uploading more spreadsheets at once doesn't make any of them finish sooner, either. They all draw from the same limited number of slots, so extra uploads just serialize behind whatever is already processing.
A list moves through a few publicly visible states: UPLOADED → ENQUEUED → PROCESSING → COMPLETED. A list can also move to FAILED from either ENQUEUED or PROCESSING. COMPLETED and FAILED are both terminal — once a list reaches one of those, its state won't change again.
There's no field in the API that reports the concurrency limit or how many lists are ahead of yours in line, so the state is the only signal you'll get. Keep polling it (or checking the dashboard) — it will move to PROCESSING automatically once a slot opens up. See the Lists API documentation for the full set of fields returned for a list.
How to make spreadsheets process faster
If you're regularly waiting on queued spreadsheets, two things actually help:
Consolidate into fewer, larger spreadsheets. The limit is on the number of spreadsheets processing at once, not on row count, so five files of 10,000 rows each will take longer overall than one file of 50,000 rows.
Add a dedicated instance. Moving to a plan with a dedicated instance, or adding an additional instance if you already have one, raises your concurrent-processing limit by 3 per instance. See Additional Instances for details.
When it's an actual problem
Queueing on its own is not something to report. Contact support if either of these happens instead: a list reaches the FAILED state, or a list stays queued for far longer than the rest of your account's activity would explain. Email [email protected] with the list ID and we will take a look.