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
| Operator | Meaning | Behavior | Example |
|---|---|---|---|
| AND | Both conditions must match | Narrows results to events satisfying every connected condition | GET AND failed |
| OR | At least one condition must match | Expands results to include either alternative | GET OR POST |
| NOT | Exclude a condition | Removes events matching the following condition | GET NOT cart |
| Implicit AND | Whitespace acts as AND between ordinary terms | Requires separate unquoted terms to appear together | GET 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 failedThis search looks for events containing both GET and failed. An explicit AND is equivalent to the usual whitespace form:
GET failedIn 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 failedUse 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_combinedThis 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 failedThis 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 failedOR is useful for alternative messages, endpoints, statuses, request methods, and error descriptions. For example, to search for two field values:
status=404 OR status=500To combine alternatives with another required condition, group the alternatives:
(GET OR POST) AND failedThis 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=500The 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 cartThis 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 cartLowercase 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 failedThe parentheses make the intended structure unambiguous:
- Evaluate whether the event matches GET or POST.
- 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_combinedThis 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=500Boolean 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 expression | Intended grouping | Expected matching behavior | Why parentheses help |
|---|---|---|---|
GET OR POST AND failed | Not made explicit | Combines alternatives and requirements without clearly showing whether failed applies to both methods | Readers must rely on assumed evaluation rules |
(GET OR POST) AND failed | GET or POST is one group, then failed is required | Matches either request method when the event also contains failed | Shows the intended relationship directly |
GET NOT (cart OR checkout) | GET is required; cart or checkout is one exclusion group | Matches GET-related events while removing either excluded category | Prevents ambiguity about what NOT applies to |
Common Search Patterns
Require both terms
term1 AND term2Use this when both conditions must match.
Match either term
term1 OR term2Use this when either condition is sufficient.
Require one term and exclude another
term1 NOT term2Use 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 term3Use this when either alternative must also satisfy a shared requirement.
Match alternative field values
field=value1 OR field=value2Use 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.