Every list in a project — Issues, Exceptions, Logs, Traces, Users, Releases, and Metrics — has the same search box, and it understands the same query language. Learn it once and it works everywhere, including the MCP server's list-* tools.

timeout environment:production browser:chrome

A query is a list of space-separated tokens. Each token is either free text or a key:value filter, and every token must match — tokens are combined with AND. There's no OR and no grouping with parentheses.

The query is kept in the page's URL (?search=...), so a filtered list can be bookmarked or shared, and sorting or paging through results keeps it. An empty query shows everything.

Free text

A token without a key: prefix is free text. It matches when it appears anywhere in one of the list's text columns (a substring match, not a whole-word one):

undefined reading

finds rows whose text contains both undefined and reading, in any order and not necessarily next to each other. To match words together, in that order, quote them:

"Cannot read properties"

Which columns free text looks at depends on the page — see Keys per page. On Metrics there are none, so free text is ignored there and only filters apply.

Filters

A key:value token filters on one field:

environment:production

No space is allowed around the :. A value that contains spaces (or a :) has to be quoted:

first_release:"1.4.0 beta"
browser:"Mobile Safari"

The same key can appear more than once; the tokens still combine with AND, so environment:production environment:staging matches nothing — nothing is in both environments at once. Use != (below) to exclude values instead.

Operators

key:value is an exact match. Put an operator right after the : to compare differently:

Operator	Meaning	Example
(none)	equals	environment:production
!=	not equal	environment:!=staging
~	contains	environment:~prod
>	greater than	name:>m
<	less than	release:<2.0.0
>=	greater than or equal	level:>=b
<=	less than or equal	release:<=1.9.9

Operators work with quoted values too: release:~"beta 2", browser:!="Mobile Safari".

A few things to keep in mind:

• environment:prod does not find production — use environment:~prod.
• >, <, >=, <= compare text alphabetically, not as versions or numbers: release:>1.10.0 is true for 1.9.0, because "9" sorts after "1". They're mostly useful for prefix ranges, not semantic versions.
• An operator that makes no sense for the key is ignored rather than reported as an error — the token is simply dropped from the query (see the notes per key below).

Yes/no keys

Keys that hold a yes/no value (like resolved on Issues) take true or false, and only support equals and !=:

resolved:false
resolved:!=true

1, yes, and on also mean true; any other value means false. ~ and >/< are ignored on these keys.

Tags and contexts

Besides a page's built-in keys, any tag you set in the SDK and any context value Buglapse stored with an event can be used as a key — this works on Exceptions, Logs, Traces, Metrics, and Users (Issues and Releases don't store tags or contexts):

plan:enterprise
region:~eu
device.platform:mobile

Contexts are stored flat, with dots in their keys — browser.name, browser.version, os.name, device.model, and so on (see the exception event). Three short aliases save typing:

Alias	Same as
browser	browser.name
os	os.name
device	device.model

so browser:chrome and browser.name:chrome are the same filter. On Logs, the log's own attributes are searched the same way: logger.info('checkout', { orderId: 42 }) can be found with orderId:42.

Tags, contexts, and attributes differ from built-in keys in a few ways:

• A key is looked up in every such field at once: plan:enterprise matches whether plan was set as a tag or as a context.
• Values are compared as text, so status:200 matches a number 200 stored by the SDK.
• Only equals, !=, and ~ work. >, <, >=, <= are ignored.
• != also matches rows that don't have the key at all: plan:!=free includes events that were never tagged with a plan.
• A key the list doesn't know and no event has matches nothing (except with !=, which matches everything).

On Issues and Releases, where there are no tags or contexts, an unknown key is ignored.

You rarely have to type these by hand: on an issue's or exception's page, and in a span's details, every tag and context value is a link that opens the matching list already filtered by it.

Keys per page

Page	Free text searches	Built-in keys
Issues	name, message	issue, resolved, environment, first_release
Exceptions	name, message	issue, environment, release + tags, contexts
Logs	message	level, environment, user + tags, contexts, attributes
Traces	trace id	environment + tags, contexts
Users	email, username, id, IP, name	email, username, external_id, ip, name + contexts
Releases	version, ref	—
Metrics	—	environment, name, session + tags, contexts

Some keys behave specially:

• issue: (Issues) finds an issue by its key. The project slug is optional and case doesn't matter — issue:MY-APP-42, issue:my-app-42, and issue:42 are the same. A value that doesn't end in a number matches nothing. Only equals is supported.
• issue: (Exceptions) takes an issue's fingerprint and lists every exception grouped into it. You don't need to type the hash: the issue page's Errors card links here with it filled in. Only equals is supported.
• resolved: (Issues) is a yes/no key.
• environment: on Issues is the environment of the issue's latest occurrence. On every other page it's the event's own environment.
• first_release: (Issues) matches issues whose first occurrence came from that release — the release page's new issues link uses it.
• release: (Exceptions) matches exceptions sent from that release.
• level: (Logs) — log, debug, info, warn, or error.
• user: (Logs) takes the internal id of an identified user — the number in the user's page address. Only equals is supported.
• session: (Metrics) is the hit's session id; name: is the hit's name.
• On Releases, the Show archived toggle next to the search box decides whether archived releases are listed; the query doesn't.

Case and wildcards

Whether upper and lower case are treated as the same depends on the database the server runs on: on PostgreSQL both free text and filter values are case-sensitive (timeout doesn't find Timeout), on SQLite they aren't for plain ASCII letters. Aliases like browser: don't change that — with PostgreSQL, type browser:Chrome the way the SDK reported it, or pick the value from autocomplete.

In free text and in ~ values, % stands for any run of characters and _ for any single character, so user_id also finds user-id and userXid. The search box has no way to escape them.

Autocomplete

The search box helps you build a query:

• Keys. Start typing and it suggests matching keys: the page's built-in keys, plus the tag and context keys found in the project's 300 most recent rows on that page.
• Values. After key: (and an optional operator) it suggests values seen for that key in the same sample, most frequent first — but only for keys with a small set of values (25 or fewer distinct ones, like environment or browser). Keys that look like free text, like email, have no value suggestions; type the value yourself.
• Presets. Focusing an empty box, or putting the cursor after a space, shows Recommended tokens — environment: for each of the project's environments, plus resolved:false / resolved:true on Issues and each level: on Logs. Picking a preset replaces a token with the same key that's already in the query, so choosing resolved:true swaps out resolved:false instead of adding a second, contradicting filter.

Use ↑ / ↓ to move through suggestions, Enter or Tab to accept one, and Esc to close the list. Enter with nothing highlighted runs the search. A suggested value that contains a space or a : is quoted for you.

Things that trip people up

• A colon makes a filter. Any word:rest token is read as a filter, even in free text — searching for https://example.com/api looks for a key named https and finds nothing useful. Quote it: "https://example.com/api".
• Filters are exact. environment:prod is not environment:production; use ~ for partial matches.
• Ignored tokens are silent. A filter with an unsupported operator (resolved:~true, issue:>10), or an unknown key on Issues or Releases, is dropped without a warning, so the list shows more than you might expect.
• Everything is AND. To see several environments, use != to exclude the others, or run the searches one at a time.

From your AI assistant

The MCP server's list-issues, list-exceptions, list-logs, list-traces, and list-users tools take a search argument in exactly this syntax, with the same keys as the matching dashboard page:

list-issues   search: "timeout environment:production resolved:false"
list-logs     search: "level:error browser:chrome"