Skip to main content

What can influence scan run time?

This article explains how long our scans usually run for, and the reasons why, in some cases, they can take a while.

Updated this week

We aim to execute scans as quickly as possible. However, during periods of high demand, scan times may be slightly longer than those listed below.

  • Usually, our scans on unauthenticated targets can take anything from 15 minutes up to 24 hours to complete.

  • For authenticated targets, the scans can sometimes take from a few hours to over 48 hours to complete.

  • For internal targets, scan times rarely exceed 12 hours.

Sometimes your scan can enter an 'Analysing Results...' state (see example)

This can occur in a rare number of cases where there is some manual intervention required by the Security Team, for example, if there is a new check that one of your targets has failed, or the check needs additional information or verification.

If this occurs, the scan will usually move to the completed state within 12 hours if this occurs during the working week, or on Monday if this occurs during the weekend.

What Should I Do If My Scan Appears Stuck or Is Taking Longer Than Expected?

Scanning delays or the appearance of a stuck scan can be caused by various factors, including the application scanning phase or system-related issues. Below, we outline common reasons for such delays and a structured approach to resolving them effectively.

Common Reasons for Slow or Stuck Scans

  1. Application Scanning Phase: The infrastructure scan usually completes fairly quickly, but the application scan includes many thorough checks, which can take some time to evaluate, particularly if the website is fairly complex. In such cases, the Intruder Portal may not reflect the exact real-time progress of the scan.

  2. Transient Issues: Temporary disruptions, such as server-side throttling or bot detection mechanisms, might cause scans to slow or stall.

Steps to Troubleshoot Scan Progress Issues

  1. Wait and Monitor: If the user interface seems unresponsive but the elapsed time is increasing, allow the scan to proceed. It may, in fact, be further along than indicated. This is especially applicable during the application phase of scanning.

  2. Investigate Interference: If the problem persists, examine the scan results for indications of server-side throttling or interference mechanisms such as bot controls. These may require adjustments or further investigation.

  3. Reach out to Support: If you continue to experience issues with your scan running for over 48-96 hours, then drop us a message in the portal, and our Support Team will be happy to take a look for you.

  4. Start a Fresh Scan: If the scan continues to take an unusually long time in excess of 48-96 hours, without signs of progress confirmed by the Support Team, consider stopping it and launching a new one. This can resolve delays caused by temporary glitches or environmental factors.

That said, there are a few factors that can influence the scan run time; some of the most common ones are listed below: In addition, if the scan appears to be stuck or running slower than expected, it may be resolving more in-depth checks in the application phase or encountering system-related issues as outlined in the troubleshooting steps provided above.

Preventive Tips

  • Plan scans during periods of low system activity or network usage.

  • Verify that no firewall or security policies are interfering with scans.


External Targets

Very large websites

The scanner uses links on each page to crawl the application, starting from the root directory (navigating to the sitemap, if linked), so if there are lots of linked pages, it could take the scanner some time to get through them all.

Advice: There's not much you can do here, just sit tight and wait for it to complete.

A large number of targets

Scan run time is less about the number of targets and more about the type of targets being scanned. That's not to say that the number of targets doesn't influence the scan run time, because it certainly can โ€“ 100 small targets would take longer than one small target โ€“ but it also stands to reason that one large target could take longer to scan than twenty small ones. It really does depend on what you're scanning.

Possible solution: Tag your targets by type (larger ones assigned one tag, and smaller ones assigned another) and use this to schedule different scans moving forward

High number of open ports & services

For each discovered service, a number of checks need to be carried out by our scanners, so if you've entered targets with hundreds or thousands of open ports running services exposed to the internet, then our scans will take longer.

Possible solution: If you only need to scan web ports (80 and 443), you can opt for 'Default Web Ports Only' (accessible via the Advanced Settings).

Intrusion prevention systems

In some rare cases, an IPS can aim to confuse scanners by making ports that are closed appear to be open, which, for the reasons mentioned above, can cause extended scan times. Some firewalls and modern edge routers even have IDS technology built in, so it may be worth double-checking if your scan is taking a long time to complete.

Multiple targets resolving to the same server

In cases where a scan contains multiple targets that all resolve to the same hosting server, the scan run time will increase. This is because our underlying scanner will evaluate each target and if it is determined that multiple targets in the scan resolve to the same destination, then the vulnerability scans for these targets will run consecutively rather than in parallel therefore causing the scan time to increase - this is because the scanner will need to wait for the scan on one target to complete before initiating the next.

Unusual configurations

Some customers have unusual networking or server configurations that can lead to long-running scans. For example, in one case, a reverse proxy was set up to serve a single website from a large number of non-standard ports. This caused our scanner to scan the same website thousands of times. If this is happening on your targets, we'll do our best to let you know about it!


Web Applications

Scans that run on targets with an authentication method configured, or targets added as an external web application, will take longer to scan than unauthenticated external targets because of the increased number of comprehensive checks.

There are other factors that can increase scan time, including the be app having a large number of parameterised URLs, convoluted path structure, or nested pages, just to mention a few.

Some of the same factors as for External Targets also apply: Intrusion Prevention Systems (IPSs), Web Application Firewalls (WAFs), large websites, and unusual configurations can increase scan run time.


Internal Targets

Large files

Some internal checks involve scanning certain files for weaknesses; if those files are very large or the system has a very big filesystem in place, it can increase scan run times.

The machine is unresponsive

If the machine is switched off, there is a problem with the network connection, or the agent is not installed correctly,ย then the scanner will attempt to connect with the agent periodically for 12 hours. (This is designed to catch systems that are switched off or otherwise unavailable, giving the system a window within which to start scanning.) If the scanner doesn't hear back once those 12 hours have elapsed, the target will be marked as unresponsive, and the scan will end.

It's worth noting, if you're scanning multiple machines at once and just one of them is unresponsive, it will delay the results for all.


Note: Advanced Scanning options and Internal Target scanning are features only available to users on the Cloud, Pro, Enterprise, and Vanguard plans.

Did this answer your question?