Octri

Search and filters

Every monitoring tab narrows the same way: build a filter visually, or type a query. Both produce the same result, and the query bar is what you'll reach for once you know the fields.

Two ways to filter

Filter builder

Pick a field, an operator, and a value. It only offers operators that make sense for the field's type, so you can't write something invalid.

Query bar

Type an expression directly. Faster once you know the fields, and it's what you paste into an alert.

Fields you can filter on

Type these names in the query bar. Most are in the builder too, under the label shown.

levelchoice

debug, info, warning, error or fatal. Builder: Level.

methodchoice

GET, POST, PUT, PATCH, DELETE, HEAD or OPTIONS. Builder: Method.

statusCodenumber

The HTTP status. Builder: Status code.

latencyMsnumber

How long the call took, in milliseconds. Builder: Latency (ms).

pathtext

The request path, such as /v1/orders. Builder: Path.

operationIdtext

The operation, as your spec names it. Builder: Operation.

messagetext

The event's message. Builder: Message.

requestIdtext

The request's id. Builder: Request ID.

releasetext

The release that sent it. Builder: Release.

environmenttext

The environment. Builder: Environment.

attemptnumber

Which attempt this was, when the SDK retried. Builder: Attempt.

fingerprinttext

What groups the event into an issue.

traceIdtext

The request's trace, shared by the client's and the server's events.

spanIdtext

The span the event happened in.

timestampdate

When it happened, compared with an ISO date such as '2026-11-01T00:00:00Z'.

Fields inside events

You can also query inside error, user, tags and context with a dot, even though the builder doesn't list them. Type these in the query bar.

sql
user.id = 'usr_8841'
tags.region = 'eu-west' AND level = 'error'
error.name IN ('SdkHttpError', 'SdkTimeoutError')
message LIKE '%timeout%' AND user.id IS NOT NULL

Operators

The query bar accepts every operator on any field: =, != (or <>), >, >=, <, <=, LIKE, NOT LIKE, IN, NOT IN, IS NULL and IS NOT NULL. The builder offers the ones that fit each field:

Field typeBuilder operators
Text=, !=, LIKE, NOT LIKE, IS NULL, IS NOT NULL
Number=, !=, >, >=, <, <=, IS NULL, IS NOT NULL
Choice=, !=, IN, IS NULL, IS NOT NULL

In LIKE, % matches any run of characters.

Combine with AND, OR, NOT and parentheses, and finish with ORDER BY <field> [ASC|DESC] or LIMIT <n>.

Examples

sql
level = 'error' AND statusCode >= 500 ORDER BY timestamp DESC
sql
path LIKE '/v1/checkout%' AND latencyMs > 2000
sql
method IN ('POST', 'PATCH') AND release = '9f2c1ab'
LIKE takes % and _ as wildcards

path LIKE '/v1/%' matches every v1 route. % matches any run of characters, _ matches exactly one.

Time range

Filters narrow what; the range narrows when. Pick a preset (1h, 6h, 24h, 7d, 30d, 90d) or set an explicit window.

Trends outlive raw events

Raw events are kept 7 days on Free, 30 on Starter, 90 on Growth, 180 on Business and 365 on Enterprise by default (or the window in your Enterprise order form). Charts past your plan's raw window read hourly rollups, but you cannot open an expired individual event.

Attempt is the one people forget

Attempt tells you whether an event was a first try or a retry. A wall of errors that are all attempt > 1 is your SDK's retry policy working, not a new outage.

sql
level = 'error' AND attempt = 1

That's the query for real first-time failures, and it is usually a much smaller number.

From a search to an alert

Any query you can run here can back a threshold alert. Get it returning exactly what you'd want to be woken for, then save it as a rule rather than writing it twice.

From the CLI

octri monitoring logs and octri monitoring issues take --q for the same search.