Search

Search within Crash Reporting allows you to view error groups and instances that match specific keyword queries. The search box is available in the top-left corner of the Crash Reporting overview page.

By default, search queries with multiple keywords will return results that match all keywords.

What can be searched?

When you perform a search within Crash Reporting, the results you get back are from matching your provided keywords against the following properties on your crash reports:

• MachineName
• Version
• Tags
• UserCustomData (You can search on both the keys and values of this dictionary)
• Breadcrumbs: Category and Message properties
• Error: Message, ClassName, and Stacktrace properties (including those of any inner errors. Up to 4096 characters worth of unique keywords from all properties of the stacktrace lines are available to search against).
• All User properties: Identifier, Email, FirstName, LastName, FullName, UUID, IsAnonymous
• Request properties: URL, QueryString and Host/HostName which is either on the Request section or found in the list of headers.
• Environment: Architecture, DeviceName, DeviceManufacturer, Model/Brand of the device
• Browser, OperatingSystem and Device information either provided on the Environment section or parsed out of a user-agent string.

The full standard Crash Reporting payload structure can be found here so that you can see where these values come from.

Property searching

In some cases you may want to refine your search further by only matching keywords on paritcular properties. This can be done with the following search syntax:

property: search term

This can be done with the following properties:

• breadcrumb (category and message values)
• customData (supports both keys and values)
• device
• exceptionType (e.g. the class name of the exception)
• innerError
• message
• queryString
• url
• stackTrace (includes up to 4096 characters worth of unique keywords from all properties of the stacktrace lines)

Partial matching

Raygun search supports partial matching, allowing Raygun to provide you with a variety of results to help narrow your search further.

Partial matching is particulary helpful when finding error reports for a specific user. For example to locate an error for user John Smith with the email person99@raygun.com, you could search for the following terms:

• john
• smith
• person99
• person99@raygun
• raygun.com
• person

Case sensitivity

Raygun search supports camel & pascal casing through partial matching. For example the term NullReferenceException will be divided into three words, null, reference and exception. Each one of these words will return results for NullReferenceException regardless of their casing.

All other queries are case sensitive. For example searching for nullreferenceexception will not return results for NullReferenceException.

Special / reserved characters

You are able to search for terms that contain a special character otherwise reserved as an operator by escaping them with a leading backslash. For instance, to search for the double-colon scope resolution operator :: used in some languages, you need to write your query as \:\:.

Likewise, you can also search for method/function calls that include brackets () - for instance the query contains\(\) will return errors that have "Contains()" in their stack trace.

The reserved characters are: + - = && || > < ! ( ) { } [ ] ^ " ~ * ? : \ /

Query by error group ID

You can search for a particular error group by ID by submitting the query errorgroupid: {{id}}. The error group ID is located after the /errors/ segment in the REST URL path for an error group. For instance, /crashreporting/{{appid}}/errors/{{errorgroupid}}.

Exact queries

Wrap a query in double-quotes, e.g. "foo-bar", which will match the raw message, separated only by whitespace. For instance, without double-quotes, exceptions will be returned which have the tokens 'foo' and 'bar', but when wrapped in quotes only exceptions with messages that contain the string 'foo-bar' will be included.

Wildcarding

The search engine supports the standard wildcard characters * and ?. When included in your search query string, these will match from all characters preceding it, to any after it (or all, if it is the final character). This is supported for both exact and non-exact queries (ones that aren't wrapped in double-quotes), but is particularly useful for the latter for precise matching.

Wildcard querying allows you to match part of a substring, by matching on any errors that have a particular field with a value that starts with that string exactly. For instance, the query "#ff*" will return any errors that include both #ffffff and #ff0000, but not #000000. The first character in the query string should not be one of the two wildcard characters above - it must be a regular character (otherwise it is ignored).

Boolean queries

Raygun Search supports common boolean logic with your supplied terms:

• AND - matches error groups where both terms exists. For instance 'foo AND bar' will return error groups that contain both 'foo' and 'bar'.
• OR - matches error groups where either term exists. For instance 'foo OR bar' will return all error groups that contain either 'foo' or 'bar'.
• NOT - matches error groups that don't contain the next term. For instance 'NOT foo' will return all error groups that don't contain 'foo'
• Sub-query grouping with brackets - specify precise boolean queries with round brackets. For example '(foo OR bar) AND baz' will return all error groups that contain 'baz' along with 'foo' or 'bar',

Please note that all boolean terms must be written in UPPER CASE, terms in lower case will not act as a boolean operator.

User search

Specific users can be searched in the Customers section. Simply enter provided user's details into the search box. The search is performed on the firstName, fullName, email, identifier and uuid field's by default. Results are ordered by the number of attributes matching the search terms.

Search across all applications

While you carry out your search within one specific application, we also run the search query across all other applications that you have access to. If there are results in other applications as well, a message above the main search results contains links to these other applications and results.