Everything Scheduled Rescan Not Running: How to Fix It

When an Everything scheduled rescan is not running, the usual symptom is straightforward: a folder index remains stale even though its update schedule says it should have been rescanned. New files may be missing, deleted files may remain in results, or the folder's last indexed time may not advance. The most likely causes are an incorrect folder schedule, Everything not running at the scheduled time, a sleeping computer, an unavailable network share, an exclusion or search filter, insufficient permissions, or a scan that is still processing.

This guide focuses specifically on scheduled folder rescans in voidtools Everything. It does not treat Everything as Windows Search. Everything maintains its own filename index and can index NTFS volumes efficiently, while folder indexing is commonly used for network shares, NAS locations, removable storage, and file systems that cannot use Everything's native NTFS indexing method. Follow the checks in order and stop as soon as a controlled test succeeds.

1. Confirm the Symptom With a Small Safe Test

Before changing settings, verify that the problem is really the folder rescan schedule. A missing result can also be caused by an active filter, restrictive search syntax, an exclusion, or a location that was never added to the folder index.

1.1 Create a test file in the affected folder

Choose the exact local folder, mapped drive, UNC share, NAS folder, or removable location whose scheduled rescan appears to have failed. Create a harmless file with a unique name, such as everything-rescan-test-2025.txt. Use a name that is unlikely to exist elsewhere.

In Everything, clear the search box and switch to a broad filter such as Everything rather than Audio, Documents, Pictures, or another content-specific filter. Search for the full test filename. If the file appears immediately, the folder may be monitored for changes successfully and the schedule is not the current problem.

If it does not appear, wait briefly and search again. Network folders and large indexes may not update instantly. Check the status bar for signs that Everything is scanning, loading, or updating its database.

1.2 Run a manual rescan

Open Everything's Options and locate the folder indexing page. Select the affected folder and use the available manual update or rescan control. The wording can differ between Everything builds, but it is commonly presented as an update, rescan, or rescan-now action.

After the operation finishes, search for the unique test filename again. Also inspect the folder entry's last indexed or last scan information where available.

• If the file appears after a manual rescan, the folder path and basic indexing process work. Concentrate on scheduling, uptime, sleep, and network availability.
• If the file still does not appear, investigate the folder definition, permissions, exclusions, filters, and account context before blaming the scheduler.
• If the rescan remains active, allow it to finish before making another change.

Success means the test file appears and the folder's indexing time advances. At that point, stop changing unrelated settings. You have established whether the failure is in scanning generally or only in the scheduled trigger.

2. Check the Folder Index and Its Update Schedule

Scheduled rescans apply to folder indexes configured in Everything. They are especially relevant to network shares and non-NTFS locations. A native NTFS volume indexed through Everything's NTFS settings normally relies on the file system's metadata and change journal rather than repeatedly walking every directory on a folder schedule.

2.1 Verify the exact indexed path

In the folder indexing options, confirm that the affected path is present and enabled. Compare it carefully with the folder where you created the test file. Similar paths can point to different places, particularly when a NAS has multiple share names or a mapped drive letter has been reassigned.

For network storage, determine whether the entry uses a mapped path such as Z:\Projects or a UNC path such as \\server\share\Projects. A mapped drive can exist in your interactive Windows session but not in the account context used by another process or service. A UNC path is often easier to reason about across account contexts, provided the relevant account has permission to access it.

Success means the configured folder resolves to the intended location and can be opened under the same Windows account that runs Everything.

2.2 Inspect the folder update schedule

Select the folder and review its rescan frequency or update schedule. Make sure it is not set to Never or to a longer interval than expected. Check the scheduled time, day, and recurrence carefully. A weekly scan can look broken if the selected day was misunderstood, while an overnight scan cannot occur if the computer is normally asleep or shut down at that time.

Everything must be running when it is expected to perform the scheduled folder rescan. The Everything service, when installed, helps with low-level indexing access, but it is not a substitute for every function of the Everything client application. Do not assume that seeing the service in Windows proves that the scheduled folder task is being processed by the user interface instance.

For diagnosis, temporarily choose a short and practical schedule, leave Everything running, keep the computer awake, and make the folder available. Do not set an extremely aggressive interval on a large NAS share because repeated directory walks can create unnecessary network and storage load.

Success means the last indexed time advances after the selected interval and the unique test file appears without a manual rescan. Once confirmed, return the schedule to an interval appropriate for the folder's size and rate of change.

2.3 Review change monitoring

Folder indexes may offer an option to attempt to monitor changes. Monitoring can make updates appear sooner, but support depends on the folder, file system, and network environment. It should not be treated as proof that a scheduled full rescan will occur.

If monitoring works, a new file may appear before the scheduled scan. If monitoring is unavailable or unreliable on a NAS, periodic rescans remain important. Test the scheduled rescan independently by checking whether the last indexed time changes at the expected time.

3. Eliminate Search Filters, Exclusions, and Result Omission

A successful scan does not guarantee that every indexed item will be visible under the current search. Before rebuilding anything, remove result-layer restrictions.

3.1 Reset the search view

Clear the search field, select the Everything filter, and disable options that limit matching to a particular file type or search mode. Then search for the exact test filename without extra operators.

Search syntax can narrow results more than expected. Path terms, regular expressions, case matching, whole-word matching, diacritics settings, and macros can all alter what is shown. Open a new Everything window if necessary and perform a plain filename search.

If the file appears after resetting the search, indexing is working. Stop troubleshooting the schedule and correct the saved search, filter, bookmark, or syntax that hid the result.

3.2 Check exclusions and omitted results

Review Everything's exclusion settings for the affected drive, folder, path pattern, and file type. An excluded parent folder can suppress everything beneath it. Also check whether results have been omitted through a temporary or persistent result-management feature.

Do not remove all exclusions indiscriminately. Instead, identify rules that could match the test path, temporarily disable only the relevant rule, and rescan. If the test file appears, refine the exclusion so it omits only the intended content.

Success means the expected file is visible with the desired exclusions still protecting locations you intentionally do not index.

4. Check Windows, Network, and Account Conditions

Scheduling can be configured correctly while Windows prevents the scan from reaching the folder. This is common with sleeping PCs, disconnected VPNs, unavailable NAS devices, mapped drives, and portable Everything installations.

4.1 Keep Everything and the computer available

For a controlled test, start Everything before the scheduled time and leave it open. Prevent the computer from sleeping until the expected rescan has completed. Confirm that Windows did not reboot for updates, sign out the user, or terminate a portable instance.

If the normal schedule occurs overnight while the PC sleeps, move it to a time when the machine is typically awake. Do not infer that a missed schedule will always be replayed exactly as expected after wake or startup. Verify behavior using the last indexed time.

Success means the scan starts while Everything is running and the computer remains awake. You can then choose a realistic schedule rather than changing permissions or rebuilding the database.

4.2 Verify network and NAS availability

Before the scheduled time, open the indexed share in File Explorer and access the test folder. Confirm that the NAS is powered on, the network connection is active, the VPN is connected if required, and stored credentials have not expired.

A share that appears in Explorer after you click it may have been disconnected before that action. For testing, establish the connection first and leave it available through the scan window. If a mapped drive is unreliable, test the equivalent UNC path as a separate temporary folder index rather than immediately replacing a working production configuration.

Success means Everything can manually rescan the same network path under the same account and can repeat that operation on schedule while the share remains online.

4.3 Compare application and service account contexts

Windows drive mappings and network credentials are account-specific. Running Everything as a different user, elevating it as administrator, or relying on a service can change which network resources are visible. An elevated process may not see the same mapped drives as a normal desktop process.

Use one consistent account context for the test. If the folder is a network share, verify that this account has permission to list folders and read filenames throughout the indexed tree. Avoid granting broad permissions merely to make indexing work. Apply only the access required by your organization and storage policy.

If security software appears relevant, review its event history and create a narrowly scoped, temporary diagnostic allowance only when justified. Do not permanently disable antivirus or firewall protection. Everything's local folder indexing does not require exposing an Everything server to the public internet.

4.4 Consider the file system type

Confirm whether the location is NTFS, ReFS, FAT, exFAT, a removable device, or a network share. Make sure it has been added using the appropriate indexing method. A folder scheduled for rescanning should be tested through the folder index configuration, while an NTFS volume may be better handled through Everything's NTFS volume indexing.

If files are missing from a native NTFS index, that is a different troubleshooting path involving volume inclusion, the Everything service, and the USN journal. Do not repeatedly add the entire NTFS volume as a folder index unless you have a specific reason.

5. Inspect Progress, Timestamps, and Diagnostic Information

Once configuration and availability have been checked, use Everything's own status information to distinguish a missed trigger from a slow or blocked scan.

5.1 Check whether a large scan is still in progress

A large share can contain millions of entries and may take substantial time to enumerate, especially over Wi-Fi, VPN, or a busy NAS. Look at the status bar and indexing options for activity. Avoid launching repeated manual scans while one is already underway.

Monitor the folder's last indexed time and the appearance of the test file. A timestamp may update only when a scan reaches a particular stage or completes, depending on the application behavior. Give the first controlled scan enough time to finish.

Success means activity ends, the last indexed information advances, and results reflect additions and deletions. Once those conditions are met, do not force a rebuild merely because the update was slower than anticipated.

5.2 Use Force Rebuild only after safer checks

Everything provides rebuilding controls for cases where the index is genuinely inconsistent. A force rebuild can be useful after confirming that paths, schedules, exclusions, permissions, and availability are correct. It should not be the first response to one missed scheduled scan.

Before rebuilding, record the folder settings and allow active indexing to finish. Then use Everything's supported rebuild control rather than manually deleting database files. Rebuilding can temporarily remove results while the index is recreated and can be expensive on large network trees.

Success means the rebuilt index includes the test file and subsequent scheduled rescans advance normally. If only the rebuild works but the next schedule fails, return to uptime, account context, and folder availability rather than rebuilding repeatedly.

5.3 Review debug output when the cause remains unclear

If Everything offers debug logging or a diagnostic console in your installed build, enable it shortly before a controlled scheduled scan. Reproduce the failure once, then stop logging. Look for messages concerning the affected path, access denial, unavailable devices, rescan initiation, or a scan already in progress.

Keep logs private because filenames and paths may reveal sensitive information. Sysadmins should capture the Everything version, installation type, account context, path type, expected schedule, actual last indexed time, and relevant diagnostic lines before requesting support.

For NTFS-specific missing results, journal diagnostics may be useful. For this scheduled folder-rescan symptom, start with folder indexing events because the NTFS change journal and a folder rescan are different mechanisms.

6. Run a Clean Temporary Test

If many settings have accumulated over time, a temporary clean profile can reveal whether the problem is configuration-specific. This is particularly useful with portable installations, copied configuration files, startup switches, or command-line options.

Do not overwrite your working profile. Close Everything after recording relevant settings, then create a separate temporary portable test in a new folder or use an officially supported isolated configuration method. Add only one small local test folder. Set a short rescan interval, create a uniquely named file, and leave the test instance running while the computer stays awake.

1. Test a small local folder first.
2. Confirm that a manual rescan finds the file.
3. Confirm that the scheduled rescan advances the last indexed time.
4. Repeat with a small folder on the affected network share.
5. Add exclusions, startup behavior, or other settings one at a time.

Review shortcuts and startup entries for command-line switches that select a different configuration, database, instance name, service mode, or startup behavior. A user may edit options in one Everything instance while launching another instance later.

Portable users should also confirm that the configuration location is writable and persistent. If settings disappear after restart, the rescan schedule may never be retained. Success means the clean instance performs a scheduled rescan. Compare it with the main profile and migrate only the necessary correction.

7. Quick Fix Checklist

• Create a unique test file in the affected indexed folder.
• Clear the search box and select the broad Everything filter.
• Confirm that the exact folder path is enabled in folder indexing.
• Run one manual rescan and wait for it to finish.
• Check whether the test file appears after the manual scan.
• Verify that the folder rescan schedule is enabled and correctly timed.
• Keep Everything running through the scheduled time.
• Keep the computer awake until the scan completes.
• Open the network share and confirm that credentials still work.
• Check whether the mapped drive is visible in the same account context.
• Review relevant folder, path, and file exclusions.
• Check the status bar for a large scan already in progress.
• Compare the folder's last indexed time before and after the test.
• Use a temporary clean profile before changing many production settings.
• Use Force Rebuild only after safer checks fail.

Stop troubleshooting as soon as the scheduled test advances the last indexed time and the unique file appears. Additional changes after success can introduce a second problem and make the original cause harder to identify.

8. Frequently Asked Questions

8.1 Does the Everything service perform scheduled folder rescans by itself?

Do not assume that the Windows service replaces the running Everything client for scheduled folder-index work. The service primarily supports access needed by Everything, particularly for low-level indexing scenarios. For a reliable test, keep the Everything application running through the scheduled time and verify the result using the folder's last indexed information.

8.2 What happens if the computer is asleep at the scheduled time?

A sleeping or powered-off computer cannot actively enumerate a folder. Move the schedule to a time when the computer and Everything are normally running, then test again. Also make sure a NAS, VPN, removable drive, or mapped share is available throughout the scan.

8.3 Why does a manual rescan work when the scheduled rescan does not?

This usually indicates that the path, permissions, and folder index are fundamentally usable. The remaining suspects are the configured interval, Everything not running, sleep or shutdown, network availability, a scan already in progress, or different account contexts between manual and scheduled use.

8.4 Why are Everything results missing even though the last indexed time changed?

Reset the search and filter, search for an exact unique filename, and review exclusions or omitted results. If only certain files are absent, verify that they are actually inside the configured folder and not behind a subfolder the indexing account cannot enumerate.

8.5 Should I delete the Everything database?

No, not as an initial fix. First test a manual rescan, verify the schedule and path, remove relevant search restrictions, check access, and let active scans finish. If the index is demonstrably inconsistent, use Everything's supported Force Rebuild function instead of manually deleting database files.

8.6 Is Everything the same as Windows Search?

No. Everything is a separate filename-search application with its own index and configuration. Changing Windows Search indexing options will not repair an Everything folder rescan schedule. Troubleshoot the folder under Everything's indexing options and use Windows only to verify permissions, connectivity, sleep, startup, and account context.