Reduce backlogs and tune concurrent crawls
Balance worker concurrency, URL count, and frequency with computer capacity.
Last checked 20 August 2026
Tune monitoring when Page checks remains backlogged, last-check times are becoming stale, or TechDash makes the computer feel busy. Start by reducing unnecessary demand. Increasing concurrency is useful only when the computer, network, and destination sites have spare capacity.
Confirm that pressure is sustained
Open Queue Status and watch Page checks over several 10-second refreshes. A hotspot begins when Waiting Jobs reaches the greater of eight or three times Workers.
A brief burst after launch, wake, reconnecting, a bulk page add, or manual checks may drain without intervention. Act when Waiting Jobs stays high or grows, all workers remain active, and scheduled checks are becoming late.
If Waiting Jobs persists while Active Jobs remains zero, do not tune concurrency first. Check activation, website pause state, internet connectivity, captive Wi-Fi sign-in, and recent application errors.
Reduce workload at the source
Use Website Pressure to find the highest-demand site and identify its main contributor:
- Open the linked website and review Monitored Pages.
- Disable or remove URLs that do not need recurring monitoring.
- Keep representative, high-value pages rather than every low-value variation.
- Change unnecessary Every 15 minutes pages to Hourly, Daily, or Weekly.
- Change unnecessary Hourly pages to Daily or Weekly.
- Investigate pages whose latest checks take at least 15 seconds.
- Investigate unexpectedly large stored HTML captures.
Frequency has a large multiplier. One Every 15 minutes page is estimated at 96 checks per day, compared with 24 Hourly checks or one Daily check. Apply the shortest intervals only where detection speed justifies the load.
Pausing a website stops its due page checks from being admitted, but the site can remain in Website Pressure because its enabled pages and stored data still exist. Disable individual pages when you want to remove them from enabled-page load calculations.
Tune Concurrent Crawls
Open Settings > Monitoring and adjust Concurrent Crawls. This controls how many Page checks can run at the same time. It does not change worker counts for SSL, Domain, DNS, Search Console, Site resources, Screenshots, or Icons.
The minimum is one. The recommended default is two when the hardware supports it. The maximum is the lower of CPU cores minus one and the RAM cap:
- less than 6 GiB RAM: one
- 6 GiB to under 12 GiB: two
- 12 GiB to under 24 GiB: four
- 24 GiB to under 48 GiB: eight
- 48 GiB or more: limited by CPU
The app always keeps the maximum at least one.
Lower concurrency when CPU or memory pressure makes the computer sluggish. This reduces simultaneous browser work, although it can make a large queue take longer to drain.
Raise concurrency cautiously when Page checks is genuinely backlogged and CPU, memory, network, and destination capacity are available. Higher is not always faster. Competing browser sessions can increase memory pressure, destination throttling, and individual check duration.
Change one level at a time, then watch Waiting Jobs, Active Jobs, Avg check, and computer responsiveness.
Account for automatic scheduling behavior
The page scheduler checks for due work every minute. Automatic admission limits waiting work to the greater of eight jobs or five times Concurrent Crawls. Manual runs bypass this limit.
Due pages are ordered most-overdue first and interleaved across websites, helping multiple sites make progress under load.
On battery power or while the screen is locked, page intervals stretch to twice their configured duration. The saved frequency does not change. This reduces background load and means a page can legitimately run later than its normal interval.
When Page checks is backlogged, screenshot and icon enrichment waits so crawls keep priority. Page checks also reduce some secondary destination probing under backlog. Delayed brand assets can therefore be a symptom of crawl pressure rather than a failed asset job.
After tuning, leave Queue Status open long enough to see a trend. Success means Waiting Jobs falls over time, last-check times recover, and the computer remains responsive. The goal is sustainable monitoring coverage, not permanently zero waiting jobs.