Recommended Exclusions

Stairwell ships with no exclusions. An environment starts collecting the default file types everywhere, which is the right default because it is the one that leaves nothing invisible. The paths below are the ones customers most often add, grouped by the problem they solve, with what each one gives up.

Use this page as a menu, not a checklist. Every row is a place Stairwell will no longer see, so add the rows you have the problem for and leave the rest.

Which exclusions are worth adding?

Almost all of these are performance exclusions, which means Do not scan is the right type unless a row says otherwise. That keeps the path out of the backscan and keeps real-time visibility of anything created, modified, or executed there. See Exclusions for why that distinction matters.

Developer machines and build servers

The single most common reason to add an exclusion. Source trees and build caches churn constantly and are dominated by intermediate output.

Anchor these to a project root or a home directory prefix where you can, and put them on a developer-machine group rather than the default policy. **/build/** on a fleet-wide policy excludes a great deal you did not intend.

Excluding whole source-language extensions across the fleet (**/*.go, **/*.ts, **/*.java, **/*.rs, and so on) is a pattern that shows up on older exclusion lists. It works, and it is broader than it looks: several of those extensions are also on Stairwell's default collection list precisely because they are executed, so a fleet-wide extension exclusion removes them from every machine including the ones where a script arriving is the thing you wanted to know about. If the goal is a quieter build server, exclude the build server's directories.

Container hosts

Container image layers can be very large and are recreated on every pull. Excluding them is usually the right call on a busy host. Be aware that a container filesystem is where a container-delivered payload lives, so if container workloads are part of your threat model, cover them another way rather than assuming this exclusion is free.

Software distribution caches

These are the safest exclusions on the page. The content is a second copy of something you distributed deliberately, and the installed result is still collected.

Message queues and log volumes

Core dumps and crash reporters

Database and storage volumes

There is no single pattern here, because the path is yours. The case for excluding a database's data directory is that the files are enormous, rewritten constantly, and not executable content. The case against is that a database server is a high-value host, so exclude the data volume and not the machine.

Name the data directory explicitly. /var/lib/<engine>/data/** is an exclusion. /var/** is a blind spot.

Which exclusions should I not add?

Some paths are tempting and expensive to lose. Do not exclude these without a specific reason you have written down.

• User profile directories and home directories. C:\Users\** and /home/** are where a phishing payload arrives, where a downloaded installer sits, and where a user-writable script gets dropped. They are also where a lot of churn is. Exclude a named subdirectory if you must, never the whole tree.
• Temp directories, wholesale. %TEMP%\** and /tmp/** are the classic staging locations for a payload that is written, executed, and deleted within seconds. If a temp directory is causing a problem, exclude the specific application subdirectory inside it.
• C:\Windows\Temp and the system32 tree. Both are routine targets for a file dropped with a legitimate-looking name.
• Anything on a domain controller, a jump host, or a build signing machine. These hosts are worth the collection cost by definition.
• Whole drives or mount points. D:\** or /** on a policy is not an exclusion, it is a decision to stop monitoring the machine. If a machine genuinely should not be collected from, do not install a forwarder on it.

Where should I put these?

In a policy attached to a group of the machines that have the problem, not in the default policy.

The default policy applies to every asset in the environment, so an exclusion added there is a fleet-wide blind spot even if you added it for six build servers. Create a policy for the cohort, attach the exclusions to it, and attach the policy to a group that selects those machines. A dynamic group keyed on hostname pattern or OS will pick up new machines of that kind as they register.

Remember that exclusions stack as a union across every group an asset belongs to, so an asset in both a general policy and a developer policy honors both sets. See Groups and Policies and Manage Groups.

What should I read next?

• Exclusions, for the two exclusion types, the per-OS field that silently disables a pattern, and how to keep a glob narrow.
• Intake Filters, when the rule is about what may be stored rather than what a host should spend effort on.
• Asset Configuration, for the resource limits and scan scheduling that sometimes solve a performance problem without an exclusion at all.