Search Syntax Reference

How Graylog Interprets Search Queries

When you enter a search query in Graylog, the system searches indexed log messages across available fields unless you limit the search to a specific field. How Graylog interprets that query depends on several rules, including case sensitivity, whitespace tokenization, wildcard behavior, and query complexity limits. Understanding these rules can help you build more precise searches and troubleshoot unexpected results.

Case Sensitivity

Graylog searches are case-sensitive by default. This is because Graylog uses a WhitespaceAnalyzer that splits terms only on whitespace (spaces, tabs, newlines).

• It does NOT lowercase terms.

• It does NOT perform stemming (i.e. reducing word variations to a common root — for example, "running," "runs," and "ran" all reduce to "run").

For example, ERROR matches ERROR but NOT error or Error.

To search case insensitively:

• Use wildcards, like *error* or *ERROR*.

• Use regex with case-insensitive flag.

Leading Wildcard Restrictions

Leading wildcards are disabled by default for performance reasons as it requires scanning the entire index, which can consume excessive memory, significantly slow queries, impact performance and cluster stability.

Query Complexity Limits

Graylog enforces a maximum clause count of 32,768 by default to help prevent resource exhaustion.

Whitespace Tokenization

Unquoted terms are split on whitespace. For example, ssh login failed is treated as ssh OR login OR failed. The OR operator is the default conjunction operator. If there is no Boolean operator between two terms, OR is used. To search for an exact phrase, enclose terms in quotes, as in "ssh login failed".

Query Parsing Process

After you submit a query, Graylog processes it in several steps before executing the search:

1. Tokenizes the query string by splitting on whitespace and identifying operators.

2. Parses the query into a query tree to validate syntax and apply field mappings.

3. Validates the query against configuration limits, such as leading wildcards and clause count.

4. Collects terms to identify which fields are being searched.

5. Executes the query against the search backend.

If parsing fails, you can verify the following:

• Operators are uppercase (AND, OR, NOT)

• Brackets and parentheses are matched

• Special characters are escaped

• Field names exist in your index

When you enter a search query in Graylog, the system searches indexed log messages. Each message contains multiple fields, such as source, type, level, http_response_code, and message. By default, Graylog searches across all fields unless you limit the query to a specific field.

Search Terms Explained

Graylog queries are built from terms and operators. Terms are the searchable words or phrases in your query, while operators control how Graylog combines or interprets them. Understanding the difference between single terms and phrases helps you write more precise searches and better predict the results Graylog returns.

There are two basic types of terms: single terms and phrases.

Single Terms

A single term is one word, such as ssh or login. By default, Graylog searches for that term across all fields unless you limit the query to a specific field. A single-term query returns messages that contain the searched term anywhere in the indexed message data.

For example, to find messages that contain the term ssh, enter:

ssh
                

You can refine a query by adding more terms; however, by default, Graylog connects terms with the OR operator, so it will search against these terms individually.

For example, the query ssh login returns messages that contain either ssh or login:

ssh login
                

Phrase

A phrase is a group of words enclosed in double quotes and searched as an exact sequence, such as "ssh login". Use a phrase search when you want Graylog to match the words together in the order entered rather than as separate terms.

The following query returns messages that contain the exact phrase:

"ssh login"
                

Phrases are case-sensitive and must match the exact sequence of terms specified. For example, "SSH login failed" returns only messages that contain that exact capitalization and word order.

Boolean Operators

Boolean operators let you combine terms and phrases to build more precise searches. You can use them to require terms, return results that match any of several terms, or exclude unwanted results. Graylog supports AND, +, OR, NOT and - operators.

AND Operator

The AND operator returns results only when both specified terms are present in the same message. Use it when you want to narrow results by requiring multiple conditions. For example: "ssh login" AND source:example.org.

AND Operator Reference

+ Operator

The + operator is an alternative syntax for AND. It makes a term required in the search results and is useful when you want to combine required terms with optional ones.

For example, the search query +level:error (ssh OR login OR authentication) returns results that MUST have level:error and MAY have any of the terms in parentheses.

The + prefix requires the specified term to be present.

+ Operator Reference

OR Operator

The OR operator returns messages that match any of the specified terms. Use it to broaden a search when more than one term or condition is acceptable.

type:ssh OR type:loginlevel:error OR level:critical

By default, terms without operators are OR-connected, so ssh login is equivalent to ssh OR login.

OR Operator Reference

NOT Operator

The NOT operator excludes messages that match the specified term or condition. Use it to filter out unwanted data from your results.

NOT Operator Reference

- Operator

The - operator is an alternative syntax for NOT. It excludes messages matching the specified term from the search results.

- Operator Reference

Fields Explained

Fields are structured data elements extracted from log messages during ingestion. Each Graylog message contains multiple fields that store specific information.

To search a specific field, enter the field name followed by a colon (:) and the search term fieldname:term. This syntax limits the query to the specified field.

The following example shows how Graylog stores log data as fields. Each piece of information in the message, such as the source, severity, or username, is stored as a separate field that you can search individually:

{
"message": "User login failed",
"timestamp": "2026-02-19 13:24:15.123",
"source": "webserver01.example.org",
"level": "error",
"type": "authentication",
"user_name": "jdoe",
"source_ip": "192.168.1.100",
"http_response_code": 401
}

Note that each key-value pair is a field. In this example:

• message contains the log text.

• timestamp contains when the event occurred.

• source contains the originating system.

• level contains the severity.

• type contains the event category.

Single Field Search

A single field search restricts your query to a specific field within log messages, making searches faster, more precise, and more efficient than searching all fields. Use fieldname:value syntax to search only the specified field for the given value. For example: type:ssh.

Multiple Terms Field Search

Search a single field for multiple possible values using parentheses with boolean operators for targeted queries. Example type:(ssh OR login).

Default Field

When no field is specified, Graylog searches all message fields. For example, a simple ssh search is equivalent to searching: message:ssh OR full_message:ssh OR source:ssh OR [all other fields]:ssh.

Analyzed Field

By default, Graylog configures some fields "type" : "text" and configures an analyzer for them. Any field that is analyzed will not allow performing literal matches against the text in that field. This also prevents regex queries from searching these fields. This affects the following fields:

• source

• message

• full_message

For most use cases, the best approach is to parse your data into specific, meaningful fields using extractors or pipelines, then search those fields directly. If you need to search the raw content of an analyzed field, you can copy it to a new field using the set_field function. Note that doing so increases your message size and may affect license usage and query performance.

You can also minimize the size impact by replacing the original field with a placeholder value after copying:

set_field("message", "-");

Grouping Explained

Grouping lets you control how Graylog evaluates a query when it contains multiple terms, fields, or operators. By using parentheses, you can combine related conditions and make sure the query runs in the order you intend. This is especially useful in more complex searches where the placement of AND and OR changes which messages are returned.

Use parentheses to control query logic. For example: (message:ssh OR message:login) AND level:error.

Nested Grouping

Nested grouping uses multiple sets of parentheses to organize more complex search conditions. This allows Graylog to evaluate related expressions together before applying the rest of the query, which helps when you need to combine several conditions in a specific way.

For example: ((message:ssh AND level:error) OR (message:login AND level:warning)) AND source:production*.

Field Grouping

Field grouping lets you apply multiple values to the same field without repeating the field name in each condition. This can make queries shorter and easier to read, especially when you want to search one field for several possible terms.

To apply operators to multiple field values, for example: message:(ssh login authentication).

This is equivalent to: message:ssh OR message:login OR message:authentication.

Term Modifiers Explained

Term modifiers change how Graylog interprets a search term. They are useful when you do not know the exact value you need to match or when you want to search for patterns instead of exact text. One common type of term modifier is the wildcard search.

Wildcard Searches

Wildcard searches in Graylog let you match patterns by using special characters in place of one or more characters in a term. This is helpful when values vary slightly, such as hostnames, domains, usernames, or other structured field values.

Wildcard Characters

Graylog supports two wildcard characters: * and ?. These wildcards work on indexed fields, but results can differ depending on whether a field is analyzed.

• ? : Replaces a single character.

  • Example: source:exam?le.org matches "example.org" or "exam8le.org".

• * : Replaces zero or more characters.

  • Example: source:*.org matches any domain ending in ".org".

  • Example: source:exam?le.* combines both wildcard characters.

By default, only the message, full_message, and source fields are analyzed. Wildcard searches on these fields behave differently from wildcard searches on non-analyzed fields. For more information, see wildcard and regexp queries.

Fuzzy Searches Explained

Fuzzy searches help you find terms that are close to, but not exactly the same as, the value you enter. This is useful when values may contain small differences, such as misspellings, transposed characters, or minor variations. In Graylog, fuzzy searches use the tilde (~) operator.

For example, roam~ matches terms similar to roam, such as foam or roams, using Damerau–Levenshtein distance.

You can also specify a custom edit distance. For example, roam~1 allows only one character difference.You can apply fuzzy searches to field-specific queries as well. For example: source:exmaple.org~.

Proximity Searches

You can also use the tilde operator with a phrase to run a proximity search. A proximity search looks for terms that appear close to each other, even if they are not in the exact order entered.

For example, "ssh login"~5 matches messages where ssh and login appear within five words of each other, in any order.

Examples that match this search:

• "ssh authentication login"

• "login attempt via ssh"

• "ssh connection login failed"

Range Searches

Range searches let you find numeric or date values that fall within a specified range. Use them when you want to search for values between defined boundaries instead of matching a single exact value.

Numeric Values

Numeric fields support range queries.

• Inclusive ranges use square brackets, like: http_response_code:[400 TO 500]. This includes all values from 400 to 500, including 400 and 500.

• Exclusive ranges use curly brackets, like: http_response_code:{400 TO 500}. This includes all values from 401 to 499, excluding 400 and 500.

• Mixed ranges let you include one boundary and exclude the other, like http_response_code:[400 TO 500}. This includes all values from 400 to 499, including 400 but excluding 500.

  You can also search with one side unbounded:

  Copy

  http_response_code:>400
  http_response_code:<400
  http_response_code:>=400
  http_response_code:<=400                    

  It is also possible to combine unbounded range operators:

  Copy

  http_response_code:>400
  http_response_code:<400
  http_response_code:>=400
  http_response_code:<=400                

Date Values

Date ranges use range searches with date fields. Date range queries are useful when you want to find messages that occurred during a specific window of time. For example: timestamp:["2019-07-23 09:53:08.175" TO "2019-07-23 09:53:08.575"] or created_at:["2019-07-23T09:53:08.175" TO "2019-07-23T09:53:08.575"].

When you run a date range query, the selected time range in the Graylog time picker must still include the dates in your query. If the time picker is set to the last five minutes, but your query searches for data from a week ago, the search returns no results.

Date values must be in UTC unless you explicitly include timezone information, and the format must match the way Graylog stores and displays the field. For example:

timestamp:["2019-07-23 09:53:08.175" TO "2019-07-23 09:53:08.575"]
                

Graylog uses a custom index mapping for the timestamp field to store dates in the format YYYY-MM-DD HH:MM:SS.sss. For other date fields recognized by the Data Node as date types, the default format is YYYY-MM-DDTHH:MM:SS.sss.

otherDate:["2019-07-23T09:53:08.175" TO "2019-07-23T09:53:08.575"]
                

You can include timezone information in a date range query. For example:

otherDate:["2020-07-29T12:00:00.000-05:00" TO "2020-07-30T15:13:00.000-05:00"]
                

You can also use relative time values to build dynamic date range queries. For example:

otherDate:[now-5d TO now-4d]
                

Regular Expressions Explained

Regular expressions (regex) let you search for text patterns instead of exact words or phrases. In Graylog, regex searches are useful when the value you want to match may vary in length, structure, or content, but still follows a recognizable pattern. This can be helpful when searching fields such as usernames, command lines, file paths, or event data with inconsistent values.

To perform a regex search, encapsulate the search term in slashes (/). For example:

field_name:/.*regex is fun!.*/

This query matches values in field_name that contain the phrase regex is fun! anywhere in the field.

event_code:4720 AND user_name:/.*\$/

This query returns messages where event_code is 4720 and the user_name field ends with a dollar sign. This is often useful for identifying machine accounts or similarly formatted usernames.

event_source_product:windows AND event_code:4688 AND process_command_line:/.* \-r.*/ AND process_command_line:/.*accepteula.*/ AND process_command_line:/.* \-s.*/ AND process_command_line:/.* \-q.*/ AND process_command_line:/.* [c-zC-Z]\:\/.*/ AND process_command_line:/.* \-r.*/

This query combines multiple field conditions with several regex patterns to find Windows process creation events whose command line contains a specific set of arguments and a drive path. Queries like this are useful when searching for command executions that may vary slightly but still follow a recognizable structure.

Escaping Explained

Some characters in Graylog queries have special meaning. They are used by the query parser as operators, grouping symbols, or wildcard characters. If you want to search for one of these characters as a literal part of a value, you must escape it with a backslash (\). Escaping tells Graylog to treat the character as plain text instead of as part of the query syntax.

The following characters must be escaped with a backslash (\):

& | : \ / + - ! ( ) { } [ ] ^ " ~ * ?

For example, to search for the literal path /posts/45326, escape each forward slash:

resource:\/posts\/45326

This tells Graylog to search for the exact value instead of interpreting the slash as part of the query syntax.

Example Queries

The following examples show common query patterns you can use in Graylog to answer specific troubleshooting, monitoring, and investigation questions. Use them as starting points, then adjust the field names, values, and operators to match your environment and data.

• Check if a field exists: _exists_:user_id

• Check if a field does not exist: NOT _exists_:user_id

• Multiple authentication types:type:(ssh OR login OR authentication OR oauth)

• Infrastructure for multiple servers:source:(webserver01 OR webserver02 OR webserver03) AND http_response_code:>399

• Client and server errors:http_response_code:[400 TO 499] OR http_response_code:[500 TO 599]

• User activity with multiple actions:user_name:admin AND (action:delete OR action:modify OR action:create)

  • Multiple wildcard patterns:source:web* OR source:app* OR source:db*

    Matches any source starting with "web", "app", or "db."

• Multiple exact phrases:"connection timeout" OR "connection refused" OR "connection reset"

• Authentication events with some form of user identification:type:authentication AND (_exists_:user_id OR _exists_:session_id)

• Application monitoring and error categories:level:error AND (exception OR timeout OR "connection refused" OR "out of memory")

Error Types Explained

When Graylog cannot interpret a query as written, it displays a warning or exception to help identify the problem. These messages can point to issues such as invalid syntax, unsupported operators, unknown fields, or undefined parameters. Paying attention to these warnings can help you correct a query more quickly and understand why it is not returning the expected results.

If Graylog detects a problem in your query, an icon with a yellow exclamation mark appears along with a message describing the warning or exception.

Common error types include:

• Parse exception: This appears when you make an error in the syntax of your search query. The error message should contain more information about the position of the syntax error.

• Invalid operator: This occurs when the operator is misspelled. For example, AND is a valid operator but and is not. operators must be uppercase.

• Unknown field: This warning occurs when you include a field in your search query that does not exist in the streams being searched.

• Parameter error: This error occurs when you are using an undeclared parameter in your search query. Parameters need to be defined before you can include them in your search.

Troubleshooting and Common Issues

The following section outlines troubleshooting steps for common issues to assist you in resolving potential challenges you may encounter.

Further Reading

Explore the following additional resources and recommended readings to expand your knowledge on related topics: