The search syntax is very close to the Lucene syntax. By default all message fields are included in the search if you don’t specify a message field to search in.

Messages that include the term ssh :


Messages that include the term ssh or login :

ssh login 

Messages that include the exact phrase ssh login :

"ssh login" 

Messages where the field type includes ssh :


Messages where the field type includes ssh or login :

type:(ssh OR login)
Hint: Elasticsearch 2.x and 5.x split queries on whitespace, so the query type:(ssh login) was equivalent to type:(ssh OR login). This is no longer the case in Elasticsearch 6.0 and you must now include an OR operator between each term.

Messages where the field type includes the exact phrase ssh login :

type:"ssh login" 

Messages that have the field type :


Messages that do not have the field type :

NOT _exists_:type 
Hint: Elasticsearch 2.x allows to use _missing_:type instead of NOT _exists_:type. This query syntax has been removed in Elasticsearch 5.0 .

Messages that match regular expression ethernet[0-9]+:

Hint: Please refer to the Elasticsearch documentation about the Regular expression syntax for details about the supported regular expression dialect.

By default all terms or phrases are OR connected so all messages that have at least one hit are returned. You can use Boolean operators and groups for control over this:

"ssh login" AND
("ssh login" AND ( OR OR _exists_:always_find_me

You can also use the NOT operator:

"ssh login" AND NOT

Note that AND, OR, and NOT are case sensitive and must be typed in all upper-case.

Wildcards: Use ? to replace a single character or * to replace zero or more characters:


Note that leading wildcards are disabled to avoid excessive memory consumption! You can enable them in your Graylog configuration file:

allow_leading_wildcard_searches = true 

Also note that message, full_message, and source are the only fields that are being analyzed by default. While wildcard searches (using *and ?) work on all indexed fields, analyzed fields will behave a little bit different. See wildcard and regexp queries for details.

Fuzziness: You can search for similar terms:

ssh logni~  

This example is using the Damerau–Levenshtein distance with a default distance of 2 and will match “ssh login” and “” (intentionally misspelled in the query).

You can change the distance like this:


You can also use the fuzziness operator to do a proximity search where the terms in a phrase can have different/fuzzy distances from each other and don’t have to be in the defined order:

"foo bar"~5 

Numeric fields support range queries. Ranges in square brackets are inclusive, curly brackets are exclusive and can even be combined:

http_response_code:[500 TO 504]
http_response_code:{400 TO 404}
bytes:{0 TO 64]
http_response_code:[0 TO 64}

You can also do searches with one side unbounded:


It is also possible to combine unbounded range operators:

http_response_code:(>=400 AND <500)

It is possible make a range query on the date field. It is important that the selected period of time at the time-picker fits the range you want to search in. If you search in the last 5 minutes, but the searched time is a week in the past the query will not return anything. The dates needs to be UTC and the format needs to be like Graylog displays them.:

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

Graylog has a custom index mapping for the field timestamp to save the date in the format like YYYY-MM-DD HH:MM:SS.sss. If one additional field where Elasticsearch has determined that this is a date and used the default date format, which is YYYY-MM-DD HH:MM:SS.sss. Means that a search in that period would be like:

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

At least with Elasticsearch 6.x, you can include timezone information in that time range. A query would look like:

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

This date query can also be dynamic, that you always look back at a specified time:

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


The following characters must be escaped with a backslash:

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



Error Types

When entering your queries be sure to look out for warning and exceptions. If you enter a query Graylog won't understand, an icon with a yellow exclamation mark appears along with a message with the warning or exception. They include:

  • Parse exception - This exception is thrown when a parsing errors occurs. 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. In most cases, operators are uppercase.
  • Unknown field - This warning occurs when you include a field in your search query that does not exist in the involved index sets. This is determined by the relationship between streams and index sets.
  • 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.