Using Boolean Expressions in Splunk Searches

Learn how to combine, expand, and exclude Splunk search terms with AND, OR, NOT, whitespace, and parentheses.

Boolean expressions let you combine search conditions in Splunk. They control whether an event must contain several conditions, may contain one of several alternatives, or must avoid an unwanted condition.

A Boolean expression is a search condition built by joining search terms or clauses with logical operators. A search term can be a word, phrase, field-value condition, or another criterion used to find events.

Splunk Boolean Operators at a Glance

OperatorMeaningBehaviorExample
ANDBoth conditions must matchNarrows results to events satisfying every connected conditionGET AND failed
ORAt least one condition must matchExpands results to include either alternativeGET OR POST
NOTExclude a conditionRemoves events matching the following conditionGET NOT cart
Implicit ANDWhitespace acts as AND between ordinary termsRequires separate unquoted terms to appear togetherGET failed

Why Boolean Expressions Matter

Searches often need more than one criterion. Boolean logic lets you:

  • Require matching terms: find events containing both a request type and an error message.
  • Allow alternatives: find events containing one of several methods, statuses, endpoints, or error descriptions.
  • Exclude unwanted events: retain a required event type while removing noise from particular categories.

The structure of an expression changes the events returned. For that reason, write the logic so another person can easily verify what the search is intended to do.

Using AND to Require Conditions

AND requires both connected terms or conditions to match. It narrows the result set because an event must satisfy every requirement joined by AND.

GET AND failed

This search looks for events containing both GET and failed. An explicit AND is equivalent to the usual whitespace form:

GET failed

In a basic Splunk search, whitespace between ordinary, unquoted search terms is interpreted as an implicit AND. Therefore, these searches express the same intended requirement:

GET AND failed
GET failed

Use explicit AND when it makes a longer expression easier to read. Whitespace is convenient for simple searches, but it can be less obvious when several operators and groups are present.

AND with field-value conditions

AND can connect field filters as well as free-text terms:

status=404 AND sourcetype=access_combined

This requires an event whose status is 404 and whose sourcetype is access_combined.

Using OR for Alternatives

OR matches an event when at least one connected term or condition is true. Use it when any one of several values is acceptable.

GET OR failed

This search returns events containing GET, events containing failed, and events containing both. Adding a second term with whitespace instead would use AND and usually reduce the results:

GET failed

OR is useful for alternative messages, endpoints, statuses, request methods, and error descriptions. For example, to search for two field values:

status=404 OR status=500

To combine alternatives with another required condition, group the alternatives:

(GET OR POST) AND failed

This means: match either GET or POST, and also require failed. Without the parentheses, the relationship between the alternatives and the required term is less clear and can produce behavior different from the intended logic.

Grouping several alternatives

Parentheses are especially useful when an OR expression contains several alternatives:

(GET OR POST OR PUT) AND status=500

The group represents the acceptable methods. The status condition is then required in addition to one of those methods.

Using NOT to Exclude Events

NOT removes events matching the condition that follows it. A useful exclusion search starts with a required base condition and then subtracts unwanted matches.

GET NOT cart

This means: find GET-related events while excluding events that match cart.

When excluding more than one category, group the alternatives after NOT:

GET NOT (cart OR checkout)

This retains GET-related events except those matching either cart or checkout. Grouping makes it clear that the entire OR expression is the exclusion condition.

Why exclusions need a required base condition

An exclusion is easier to reason about when the search first states what must be present. Compare an expression that begins with a required event type to one that only describes what should not appear. Starting with the required condition helps prevent unrelated events from entering the result set and makes the purpose of NOT clear.

Operator Capitalization

Write Boolean keywords in uppercase so Splunk recognizes them as Boolean operators:

GET OR POST
GET AND failed
GET NOT cart

Lowercase words such as or, and, or not may be treated as ordinary search text rather than as Boolean operators. If a search behaves as though the operator itself is a keyword, check its capitalization first.

Parentheses and Grouping

Parentheses define a group of conditions that should be evaluated together. Explicit grouping is important whenever an expression combines more than one Boolean operator.

(GET OR POST) AND failed

The parentheses make the intended structure unambiguous:

  1. Evaluate whether the event matches GET or POST.
  2. Require that grouped result to also match failed.

Parentheses also make exclusions precise:

GET NOT (cart OR checkout)

Here, the excluded group is either cart or checkout, and the required base condition is GET.

Field-value examples with grouping

Boolean operators can connect field-value conditions:

(status=404 OR status=500) AND sourcetype=access_combined

This searches for events from the access_combined sourcetype whose status is either 404 or 500.

Field alternatives can also be written in a compact form when the field condition is repeated:

status=404 OR status=500

Boolean Evaluation and Search Readability

Operator precedence is the order in which parts of a Boolean expression are evaluated. Parenthetical groups take priority because they explicitly define which conditions belong together.

In a complex search, do not make readers infer the intended precedence from a mixture of AND, OR, NOT, and whitespace. Add parentheses around every meaningful alternative or exclusion group:

(GET OR POST) AND (failed OR timeout) NOT (cart OR checkout)

This structure communicates the intended logic:

  • The event uses GET or POST.
  • The event contains failed or timeout.
  • The event does not match cart or checkout.

Formatting also helps during troubleshooting. Put related conditions together, use explicit uppercase operators, and review each group as a separate requirement or exclusion.

Grouped and Ungrouped Search Logic

Search expressionIntended groupingExpected matching behaviorWhy parentheses help
GET OR POST AND failedNot made explicitCombines alternatives and requirements without clearly showing whether failed applies to both methodsReaders must rely on assumed evaluation rules
(GET OR POST) AND failedGET or POST is one group, then failed is requiredMatches either request method when the event also contains failedShows the intended relationship directly
GET NOT (cart OR checkout)GET is required; cart or checkout is one exclusion groupMatches GET-related events while removing either excluded categoryPrevents ambiguity about what NOT applies to

Common Search Patterns

Require both terms

term1 AND term2

Use this when both conditions must match.

Match either term

term1 OR term2

Use this when either condition is sufficient.

Require one term and exclude another

term1 NOT term2

Use this when the first condition defines the result set and the second condition represents noise to remove.

Group alternatives before applying another condition

(term1 OR term2) AND term3

Use this when either alternative must also satisfy a shared requirement.

Match alternative field values

field=value1 OR field=value2

Use this when a field may contain one of several accepted values.

Troubleshooting Boolean Searches

<

The operator behaves like a search word

Problem: A search for alternatives returns no results or behaves as though the operator is ordinary text.

Likely cause: The operator was typed in lowercase or mixed case.

Resolution: Use uppercase AND, OR, and NOT.

A mixed AND/OR search returns unexpected results

Problem: The result count is larger or smaller than expected.

Likely cause: The intended logical grouping was not made explicit.

Resolution: Add parentheses around alternatives, shared requirements, or exclusions. For example, use (GET OR POST) AND failed when failed must apply to either method.

NOT removes unexpected events

Problem: An exclusion removes more or fewer events than intended.

Likely cause: NOT was applied without a clear required base condition, or excluded alternatives were not grouped.

Resolution: Start with the required condition and group the exclusions, such as GET NOT (cart OR checkout).

Adding a second word reduces results

Problem: Adding another search word unexpectedly reduces the result set.

Likely cause: Whitespace is acting as an implicit AND.

Resolution: Use OR when either word should be sufficient, and use parentheses when those alternatives are combined with other logic.

Exam-Relevant Notes

  • AND requires both connected conditions.
  • Whitespace between ordinary search terms commonly represents an implicit AND.
  • OR matches when at least one connected condition is true.
  • NOT excludes events matching its following condition.
  • Boolean operators should be written in uppercase.
  • Parentheses explicitly control grouping and make mixed expressions easier to verify.
  • Use a required base condition before an exclusion whenever possible.

For reliable searches, state the required events first, group alternatives with parentheses, group exclusions after NOT, and avoid relying on readers to infer precedence.

See also: Boolean Expressions.