A result limit that looks valid when you pick it should not turn out to be invalid the moment the run starts.
What changed
The Maps Scraper interface let you choose a result limit for a run, but that limit was not always aligned with what the backend actually accepted as valid. In practice, this meant a value you selected and confirmed in the interface could be rejected once the run tried to use it, which caused the run to auto-pause partway through instead of completing. The interface and the backend were, in effect, working from two different sets of rules about what counted as an acceptable limit, and you only found out they disagreed once a run was already underway.
This is now fixed. The result limit options shown in the interface match what the backend accepts, so a limit you select is guaranteed to be valid for the run you start. There is no longer a gap between what the setup screen presents as an option and what the run itself will actually honor.
This kind of mismatch is a particularly frustrating class of bug because it does not fail immediately. A run could start normally, make progress, and only hit the auto-pause once it reached the point where the invalid limit mattered, which meant time and resources were already spent before the failure surfaced.
The underlying issue was that the interface and the backend had drifted apart over time in what they each considered a valid range for results. The setup screen kept offering options that had been valid at some earlier point, while the backend's actual accepted range had since changed. Neither side was wrong in isolation; they had simply stopped agreeing with each other. Fixing this meant bringing both back into alignment so the values you see are always the values that will work.
How to use it
Set up a Maps Scraper run the same way you always have, choosing a result limit from the options available. You should no longer see runs auto-pause due to a mismatched limit, since every option shown to you now reflects a value the backend will actually accept.
If you have an existing scheduled run that was previously getting paused this way, it should now run through to completion with its configured limit, without you needing to go back and manually adjust the setting. If you had previously worked around this by guessing at a lower, "safer" limit than what you actually wanted, you can now go back and set the limit to what you actually need, since the option presented to you is a real, working value.
If you are setting up a new run, there is nothing extra to check. The available options in the interface are the ones that work, so picking any listed value should carry the run through to completion without an unexpected auto-pause.
If you run Maps Scraper on a recurring schedule to keep a steady stream of local leads coming in, this is worth verifying once by letting the next scheduled run complete and checking that it finished with its full configured result count rather than pausing partway through. Once you have confirmed that, you should not need to check again, since the underlying mismatch that caused the auto-pause is resolved at the source rather than patched around it.
Why it matters
An auto-paused run with no clear explanation just looks broken, and it means you have to notice the pause, figure out what happened, and restart manually. For anyone relying on Maps Scraper to source local business leads on a schedule, a run that silently stops partway through is worse than a run that fails immediately, because you might not notice until you go looking for results that never fully materialized.
Matching the interface's accepted values to what the backend actually supports removes that failure mode entirely: what you pick is what runs, and what runs is what completes. That consistency is what makes it possible to trust a scraper run enough to schedule it and walk away, rather than needing to babysit every run to make sure it actually finished.
This is especially important if you use Maps Scraper as an early step feeding a larger workflow, where the results go straight into a lead list and then into a campaign. A run that quietly auto-pauses partway through means the downstream campaign starts with fewer contacts than intended, and unless you go back and specifically check the scraper run, there is no obvious signal in the campaign itself that anything upstream came up short.
Removing this mismatch also means the result limit you choose is a real commitment you can plan around. If you set a limit expecting a certain volume of leads to work with, you can now count on getting that volume, rather than treating the configured limit as a best-effort target that might get interrupted before it is reached.
This fix is a good reminder that a tool built on scraping local business listings needs both halves, the interface you configure and the backend that actually does the work, to agree on the rules every single time, not just most of the time. A single mismatched value is a small thing individually, but it is the kind of small thing that erodes confidence in a scheduled, unattended tool faster than almost anything else, since the entire value of scheduling a run is not having to watch it.
If you had adjusted your workflow to work around the auto-pause, for example by breaking a large target result count into several smaller runs so each one was less likely to hit the mismatched limit, you should be able to return to configuring a single run with the volume you actually want. The workaround is no longer necessary now that the interface and the backend agree on what a valid limit looks like.
A scraper you can configure once and trust to run unattended is worth more than the sum of its individual results, since the real value is in the time it frees up for everything else on your plate. Restoring that trust is the actual point of this fix, more than any single run it happens to save from an early auto-pause.
Availability
This fix applies to all Maps Scraper runs going forward.