How to Manage a Scan Queue and Retry Failed Local Rank Scans
How to Manage a Scan Queue and Retry Failed Local Rank Scans
Managing a scan queue comes down to four habits. Batch your scans by client and by grid. Give each scan a fixed place in the schedule. Retry only the failures that are worth retrying, and only once you know why they failed. Report anything unfinished as unfinished instead of as a bad ranking. This guide covers each habit for agencies running Google Maps grid scans across many clients.
TL;DR
- A queued scan is normally waiting for capacity, not broken. Check the scan’s status and its position before you resubmit anything.
- Retry by failure type. Timeouts and connection errors deserve a retry. Parse errors and blocked responses do not deserve an instant one.
- Never retry blindly. A duplicate submission can spend a second credit, so confirm the first scan is really dead.
- Lock grid size, spacing and center point at baseline so a rerun is comparable with the original.
- In client reports, show failed or pending points as missing data with a denominator. Never show them as rank 20+.
Table of Contents
- What a scan queue is and why scans wait
- How to check a queued scan before you do anything
- Organize the queue so it rarely backs up
- Budget your credits before you queue
- Why scans fail, and what to do about each type
- Don’t react to one bad scan
- Report delays and failures honestly
- Perspective: why predictable queues start with predictable pricing
- Run your queue with Maprank
- A weekly routine for a healthy queue
- FAQ
- Sources
What a scan queue is and why scans wait
A grid scan is not one search. A 7x7 grid is 49 separate location-based searches, and a 9x9 grid is 81. Multiply that by keywords, by businesses and by clients, and a single Monday-morning batch can be thousands of requests. The queue exists so those requests are processed in an orderly way instead of all at once.
Waiting in a queue is a normal state in any scanning system. Security scanners work the same way: a request waits until the next available scanner can take it. Rank-tracking scans behave the same. Four things usually decide how long a scan waits:
- Volume ahead of you. Many scans submitted in the same window share the same processing capacity.
- Grid size. A larger grid has more points to finish, so it takes longer to clear even after it starts.
- Slow or difficult markets. Some searches take longer to return a clean result than others. A job without a time limit can hold up the ones behind it.
- Scheduling collisions. If every client is set to run at 9:00 on Monday, your own schedule creates the traffic jam.
The last cause is the one you control, which is why most of this guide is about scheduling.
How to check a queued scan before you do anything
The most common mistake is cancelling and resubmitting a scan that was only waiting. Work through this order first.
- Read the status. Is it queued, running, partially complete, completed or failed? Each one calls for a different response. Only a failed scan should be retried.
- Look at progress, not just state. A running scan that has finished 40 of 49 points is moving. Give it time.
- Compare against what you submitted. Count how many scans you launched in the last hour. If you queued a whole client roster at once, the delay is probably yours.
- Check the age. Decide your own tolerance up front. For example, anything still queued after your normal reporting window deserves a closer look. A scan that has sat far longer than usual for its size is the one to investigate.
- Only then act. If it is truly stuck or failed, follow the retry rules below.
Write your tolerance down for the team. When everyone uses the same threshold, nobody panics at 9:05 and double-submits.
Organize the queue so it rarely backs up
A clean queue starts with a clean schedule. These rules keep both the queue and the data tidy.
Stagger by client, not by hour
Spread clients across days and time windows. Put your largest grids on their own slot so they do not hold up smaller clients. A simple pattern: big multi-location accounts early in the week, single-location clients midweek, ad hoc checks on the remaining days.
Keep the same day and time window
Google’s local results shift during the day and across the week. Running a client on the same weekday and time window every cycle removes one source of variation, so a change in the grid more likely reflects a real change. Pick the slot once and leave it.
Lock the grid settings at baseline
A grid is a small geographic experiment. Its control variables are grid size, point spacing and the exact center coordinates. Change any of them and the new scan can no longer be compared with the old ones. Record all three in a one-page setup note for each client. If a change is unavoidable, such as a client moving premises or a wider service area, write down the date and start a fresh baseline instead of splicing two different grids into one trend line.
This is also where customizable grids earn their keep. Maprank lets you set the grid size and spacing per scan, so you can match the grid to the client’s real service area. Choose it carefully at the start, then keep it.
Group by purpose
Use a naming convention that makes the queue readable at a glance: client, business, keyword, grid, and whether the scan is a scheduled baseline run or a one-off. When something stalls, you will know in seconds whose report it affects.
If you manage many accounts, our guide to tracking Google Maps rankings for multiple locations goes deeper on structuring the roster. For recurring runs, the piece on automated Google Maps rank tracking shows how to set the schedule once.
Budget your credits before you queue
Because Maprank prices by scan credits, the queue is also a budget. Before a big batch, work out the cost: the number of scans times the credits per scan for the grid you chose. A 9x9 grid across five keywords for ten clients is a very different number from a 5x5 grid for one keyword.
Our plans are published at maprank.so: Solo is $19 per month ($228 per year), Agency is $39 per month ($468 per year), Pro is $79 per month ($948 per year), and Scale is $149 per month ($1,788 per year). Every plan includes unlimited businesses and white label features. Credits, seats and grid size are what scale by plan. Adding a client does not add a fee.
Planning credits ahead has a side benefit. You will not be tempted to rerun a scan “just to see” when the real answer is that you should wait for the next scheduled cycle.
Why scans fail, and what to do about each type
Not every failure is the same, and a good retry policy treats them differently. A retry loop that hammers a problem can turn one failure into many. Give each scan a small, fixed retry allowance by failure class.
| Failure type | What it usually means | Best response |
|---|---|---|
| Timeout or connection error | A temporary network or processing hiccup | Retry up to twice, with a short pause between attempts |
| Rate limit response (HTTP 429) | Too many requests too fast | Wait through the cooldown, then retry once |
| Blocked or challenge page | The request was flagged | Do not retry immediately. Requeue for a later window |
| Parse or empty result | The response came back but could not be read, or the result looks wrong | Do not retry blindly. Inspect it, flag it, and fix the cause |
| Wrong business matched | The tracked listing did not match the result | Check the business name, address and category settings, then rerun |
These limits are a sensible house rule, not a law. The principle is what matters: retry when the cause is likely temporary, wait when the cause is pressure, and investigate when the cause is the data itself.
Retry safely: avoid paying twice
In any credit-based system, a duplicate submission can cost a second credit. Some APIs handle this with an idempotency key, a unique token sent with a request so that a repeat returns the original result instead of starting new work. GEOpta’s API documentation describes this pattern, where a retry carrying the same key returns the first response instead of charging again.
Whether you use an API or a dashboard, the habit is the same. Before you retry, confirm the first attempt is truly finished and failed. If it is still processing, a second request only adds to the queue.
Confirm the retry worked
A retry is not a success until you verify it. Check these four things:
- Status: the scan shows completed, not partially complete.
- Coverage: every point in the grid returned a result, or you know exactly which points are missing.
- Sanity: the results make sense for this business. A listing that ranked 2 last week and now shows no rank anywhere deserves a second look before it goes in a report.
- Duplicates: you have one completed scan for that slot, not two.
Validation matters beyond rank tracking. Anyone who acts on incoming data should check it before trusting it. Local service businesses apply the same discipline when they set up Facebook lead alerts, because a signal is only useful once you know it is real. The same applies to a scan: check it, then act on it.
Don’t react to one bad scan
Local pack positions move from day to day. A single scan is a snapshot, and a snapshot can land on a bad day. Before you rerun a scan because a number looks worse, ask whether the change is bigger than ordinary movement.
A more reliable approach is to compare across several runs. Many practitioners use a rolling median of the last three scans for each keyword and grid, and mark known Google update dates on the timeline. A dip that survives three scans is a trend. A dip that appears once is often noise, and rerunning it only burns credits.
That said, a rerun is right when you suspect the scan itself was faulty: many points missing, a business mismatch, or a result set that is obviously empty. The question to ask is whether the scan failed or the ranking changed.
Report delays and failures honestly
Clients see the report, not the queue. How you present incomplete data decides whether they trust the rest of it.
- Never turn a failed point into a bad rank. A search that did not finish produced no observation. It is missing data, not a rank of 20+. Counting it as a loss makes the map look worse than reality.
- Show the denominator. Calculate top-three coverage from the points that completed successfully: points ranking 1 to 3 divided by all successful points. Then state how many points completed out of how many were requested, for example 46 of 49.
- Label provisional results. If a scan is still running when you pull the report, say the map is incomplete and the figures may change.
- Keep the comparison fair. Compare like with like: the same grid, the same spacing, the same time window. If you changed the grid, say so and show the new baseline date.
- Explain in one sentence. Something like “3 of 49 points did not return data this cycle and are excluded from coverage; we will rerun them in the next window.” Clients rarely object to a plain statement. They object to surprises.
Because Maprank reports can be white-labeled on your own domain, you can build this note into the way you present every report. Clients see your brand and your standard, which supports retention.
Perspective: why predictable queues start with predictable pricing
Most queue trouble we hear about from agencies is not a technical mystery. It is a planning problem that pricing makes worse. When every extra location or team member adds a fee, agencies start hoarding scans, skipping clients and rerunning only the accounts that shout loudest. The queue fills with panic submissions.
We built Maprank around the opposite idea. Every plan includes unlimited businesses and white label reporting, and you pay for scan credits, seats and grid size. You can plan a cycle, assign every client a slot, and spend credits on purpose.
We also think you should never have to hand over Google account access to track a client. Fewer connections means fewer things that can break a scheduled run at 6 a.m. on a Monday.
Our advice: choose the grid once, lock it, schedule it, and let the cycle run. Reserve manual reruns for scans that genuinely failed.
Local
Run your queue with Maprank
If you are tired of per-location fees and unpredictable bills, Maprank gives you grid-based Google Maps rank tracking with customizable scan grids, white label reports on your own domain, unlimited businesses on every plan and straightforward per-scan credit pricing. Plans start at $19 per month for Solo, and you can compare all four on the Maprank pricing page.
Just need to see where one business stands right now? Try a one-off Google Maps rank check before committing to a recurring plan. For more on how scheduled tracking fits together, read about daily Google Maps rank monitoring.
A weekly routine for a healthy queue
To make this concrete, here is a routine an agency of any size can adopt.
- Monday, before launch: review last week’s incomplete scans. Decide which need a rerun and which can wait for the next cycle.
- Monday to Wednesday: run scheduled scans in staggered slots, largest grids first in their own window.
- Thursday: scan the status list for failed or partial scans. Sort them by failure type using the table above and apply the retry allowance.
- Friday: verify the retried scans, check for duplicates, and prepare client reports with coverage denominators and any provisional labels.
- Monthly: review your setup notes. Confirm that no client’s grid, spacing or center point changed without a recorded baseline date.
This takes minutes per week once it is habit, and it prevents the two expensive mistakes: duplicate scans and reports built on incomplete maps.
FAQ
Why is my scan still queued?
Usually it is waiting for processing capacity, often because many scans were submitted at once or the grid is large. Check the status and progress first. If the scan has been waiting far longer than normal for its size, then investigate further. Resubmitting too early often adds a second copy to the queue.
Should I retry a failed scan immediately?
It depends on why it failed. Timeouts and connection errors are worth a quick retry, up to twice. Rate-limit responses should wait through a cooldown. Blocked responses and unreadable results should be requeued for a later window or investigated, not hammered.
Will retrying a scan cost extra credits?
It can in any credit-based system if the original scan completed or is still processing. Before retrying, confirm the first attempt failed. Check your plan’s credit balance and your account details for how failed scans are counted.
How do I show a failed point in a client report?
Show it as missing data, not as a poor rank. Calculate coverage from the successful points, state how many points completed out of those requested, and note that the missing points will be rerun. This keeps the map honest and the trend comparable.
How often should I rerun a scan?
On your normal schedule, at the same weekday and time window each cycle. Compare a rolling median of recent scans instead of reacting to a single snapshot. Rerun outside the schedule only when the scan itself looks faulty.