One query language serves two things in a report, a search and a filter:

• The search (5.11.0): the search button on the title line, or /, opens a query builder, and Enter runs the query. The Search tab lists the scenarios that match, with the lines where each one matched, and a result you pick takes you to it (below). A search hides nothing.
• The filter field, at the top of the filter box that the report bar's Filters button opens: it narrows the Features list as you type, hiding the scenarios that do not match, as the filter rows hide theirs.

Both take text, tags and statuses, the tag:, status:, feature:, dep:, duration: and is:happy qualifiers (below), and boolean operators.

This page was called Search Syntax up to 5.9.0, when the filter box's text field and its help called its filtering a search, and Filter Syntax from 5.9.1, which called it a filter. 5.11.0 added the search, and the page became Search and Filter Syntax, at the same address. 5.11.0 also ran the search through the filter, its query the filter's, with the field gone from the box. From 5.12.0 the two are apart again: the filter field is back in the box, as #searchbar, with its query in the page's link as q=, and the search's query is search=.

Tip: Press / anywhere in the report to open the search. Search syntax tips at the foot of the query builder, and the ? beside the filter field, are a quick syntax reference.

Type any word to filter scenarios by feature name, feature description, scenario name, step text (background steps included, 3.0.48+), error messages, tags (the scenario's and its feature's), the services a scenario calls and the paths of its HTTP calls. Of a diagram, that is all the instant filter reads; once a word has three letters, deep filtering also reads payloads, headers, SQL, whole diagrams and stack traces (below).

order

You can also filter by feature name to keep all the scenarios of a feature:

Pancakes Creation

Multiple words are treated as implicit AND — all words must appear:

order create

Wrap text in double quotes for exact phrase matching:

"delete order"

This matches "Delete order fails gracefully" but not "Order was deleted".

When you use &&, ||, or !!, the filter switches to advanced mode with full boolean expression support.

From highest to lowest:

1. !! (NOT)
2. && (AND)
3. || (OR)

Use parentheses to override precedence:

payment || order && create     → payment || (order && create)
(payment || order) && create   → matches both "payment" and "create", or "order" and "create"

In advanced mode, adjacent operands without an explicit operator are joined with implicit AND. This means:

@smoke $failed "order"

is equivalent to:

@smoke && $failed && "order"

You can mix implicit and explicit operators freely.

Filter by tags using the @ prefix:

@smoke
@api && @smoke
@"Happy Path"
tag:smoke
-tag:slow

@smoke matches a scenario that carries the tag smoke, in any case. A scenario's tags are its feature's tags and its own, the same tags the report's Tags row shows, Happy Path included (Tags and Attributes › Tags). Quote a tag that has a space in it: @"Happy Path", @"two words". Quoting works in advanced queries and in the legacy expressions below.

From 5.11.0 tag:smoke and tag:"two words" are the same tests as @smoke and @"two words", and take part in &&, ||, !! and brackets as they do. A - right before one leaves those scenarios out: -tag:slow is !!@slow.

Before 5.0.0 @tag read a scenario's own labels and categories only: not its feature's tags, and not Happy Path.

When not using advanced operators (&&/||/!!), you can use Cucumber-style tag expressions with English keywords:

@smoke and @api
@smoke or @regression
not @slow
(@ui or @api) and not @slow

Each side of every and and or is read, and a bracket written against a tag is a word of its own, so the last line works as written; a tag keeps the brackets it closes (@issue(12)). Before 5.2.7, a side the expression could answer without was left unread and the expression stopped there (@a and @b or @c missed a scenario tagged only c), and the brackets were read into the words beside them.

Note: Legacy tag expressions are only available when no advanced operators are present in the query. If you use &&, ||, !!, $status, or from 5.11.0 tag: or status:, anywhere in the query, use @tag with the advanced operators instead.

Filter by test execution status using the $ prefix, or from 5.11.0 the status: qualifier:

$failed
$passed
$skipped
status:failed
-status:passed

status:failed is the same test as $failed, and -status:passed leaves the passed scenarios out, as !!$passed does.

$skipped and status:skipped keep the scenarios skipped after a failure too, as the summary, the ring and the Status row's Skipped button count them (5.9.1; before, $skipped missed them, and the Status row's Failed button showed them). $skippedafterfailure keeps those alone.

Combine with other operators:

$failed && order
$passed || $skipped
@api && $failed

Note: $status is an advanced-mode feature. It switches advanced mode on automatically, even without explicit &&/||/!! operators. From 5.11.0 status: and tag: switch it on too.

The verdict operators below apply in a report drawn with ShowScenarioHistory = true (4.6.0). In such a report, when the run read a cross-run history ledger (3.11.0), each scenario also carries its verdicts, and they take the same $ sigil, or from 5.11.0 status: (status:flaky):

$flaky
$broke
$failed && !!$flaky        # the regressions: failing now, and not the ones that flip
$passed && $flaky          # flaky scenarios that happened to pass this time
$stable

The vocabulary is stable, new, broke, failing, always-failing, fixed, flaky, slower, behaviour-changed, reordered, unstable-shape, quarantined and unknown — see the verdicts for what each is measured from. A scenario carries every verdict that applies, so $flaky finds one whose status is Passed and $failed && $flaky finds one that is both. An execution-result name always means the status: $failed is the scenarios that failed in this run and is never looked up as a verdict, so nothing that worked before 3.11.0 reads differently. A default report carries no verdicts (since 4.6.0 they are on the labs page beside it), and neither does a report generated with no ledger: in either, a verdict query matches nothing, without an error. status: reads only the names of a status and of the verdicts this report's scenarios carry: any other, such as status:flaky in a report without verdicts, is searched as text, and the search says so.

A qualifier is a key, a colon and a value, with no space after the colon. dep:, duration: and is:happy (5.0.0), and feature: (5.11.0), narrow the filter as the filter rows do. tag: and status: (5.11.0) are another way to write @tag and $status (above).

feature:pancakes (5.11.0) keeps the scenarios of a feature whose name holds pancakes, in any case. Quote a name with a space in it (feature:"pancakes creation"), and separate names with commas to keep the scenarios of any of them (feature:pancakes,waffles). Inside a feature, the query builder offers the search in that feature alone, as feature:"Pancakes Creation" before what you typed.

dep:payment keeps the scenarios that call a dependency whose name holds payment: one of the participants the Dependencies row lists for the scenario. Case, spaces and punctuation are ignored on both sides, so dep:orderservice finds Order Service and order-service. Quote a name with a space in it (dep:"order service"), and separate names with commas to keep a scenario that calls any of them (dep:payment,order).

duration: compares a scenario's own time, its recorded duration less the first-call warm-up it paid, as the Duration row does (Why is my first scenario slow?):

• An operator and a time: >, >=, <, <= or =, as in duration:<500ms. With no operator the time is a minimum, so duration:2s is duration:>=2s. = matches a time within half a millisecond.
• A range, both ends included: duration:1s..5s.
• A time is a number with ms, s, m or min after it, a decimal point allowed (duration:>1.5s); a number alone is seconds. p50, p90, p95 and p99 are this report's percentiles, the times the Duration row's buttons show: duration:>=p90.

A scenario with no recorded duration is never kept by duration:, and always kept by !!duration:.

is:happy keeps the scenarios marked as happy paths, the ones the Happy paths filter shows on Only (Tags and Attributes). is:happy-path, is:happypath and their plurals are the same.

• A qualifier stands on its own: at the start of the query, or after a space or (, and never inside quotes ("order dep:payment" is a phrase; before 5.2.7 the qualifier inside it was read).
• !! or not before a qualifier keeps the scenarios it would leave out: !!dep:payment, not is:happy (not since 5.2.7; before, not dep:payment kept the scenarios that call payment). From 5.11.0 so does a - right before any qualifier: -dep:payment, -feature:audit, -duration:>2s, -tag:slow, -status:passed. A - before a word that is not a qualifier is part of the word. Negate tag: and status: with !! or -: either switches advanced mode on, where not is a word to find.
• feature:, dep:, duration: and is: always narrow. They combine with the rest of the query, and with each other, by AND, whatever operator stands beside them: order || dep:payment keeps the scenarios that match order and call a payment dependency, and so does @smoke and dep:payment in a legacy tag expression (before 5.2.7 the and it left behind matched nothing). Put the alternatives inside one qualifier instead (dep:payment,order). tag: and status: take part in &&, || and brackets as @ and $ do, so tag:smoke || tag:api keeps either.
• A feature:, dep:, duration: or is: inside a group that !! or not negates, such as !!(dep:payment), cannot narrow the query: it stays in it as text, the field it was typed in turns amber, and for a search the Search tab says why (5.2.7; before, it was read as dep:payment and kept the scenarios the query meant to leave out). Write !!dep:payment instead.
• dep: compares names in every alphabet, dep:ödeme and dep:支付 among them (5.2.7; before, only a to z and 0 to 9 were compared, so dep:ödeme matched Deme Service).
• The keys are tag:, status:, feature:, dep:, dependency:, duration: and is:, in any case; milk: is text. Before 5.11.0 tag:, status: and feature: were text too.
• A qualifier the search cannot read, such as duration:fast, duration:"", is:sad, status:400 or a percentile in a report with no durations, stays in the query as text: the field it was typed in turns amber, the query builder's or the filter field's, and for a search a line over the Search tab's results says why, as in "duration:fast was searched as text: a duration is a time such as 2s, a range such as 1s..5s, or a percentile such as p90." (duration:"" stopped the filter altogether before 5.2.7.)
• They are part of the query, so the page's link carries them: in q= for the filter field, in search= for the search. Clear All clears the filter field's.

You can freely mix text, tags, status, and operators:

@api && $failed && !!timeout
(order || payment) && $passed
@smoke && "expected result" && !!@slow
$failed dep:payment duration:>1s
tag:api status:failed -dep:payment

The query, once Enter runs it (5.11.0; until then it ran as it was typed), matches at once against:

• Scenario display name (the name the test was given, or its method's name as a sentence)
• Feature and scenario descriptions, feature endpoint (3.0.72+)
• Step text (Given/When/Then steps, background steps and nested sub-steps)
• Error messages (for failed scenarios)
• Parameterized example values (3.0.70+)
• Diagram participant names and the paths of HTTP calls: from 5.11.0 a call's path is read with internal-flow tracking on, which is the default, and a long path is read whole. Until then such a call's path was found only by deep filtering, and a long one was read to its first 100 characters.
• Tags, the scenario's and its feature's (as text, and by name with @tag or tag:)
• Status (with $status or status: only)
• Own time (via the duration: qualifier only, 5.0.0)
• Dependencies and happy paths as the filter rows pick them, with dep: and is:happy (5.0.0); a dependency's name also matches as text, as a participant name, and a happy path by its Happy Path tag
• The feature's name, with feature: (5.11.0), besides matching as text

Reports embed a compact full-text index over everything the report contains, so the same search also matches text that only exists inside (up to 5.9.0 this was called deep search):

• Note payloads — request/response bodies, headers, assertion notes
• Full diagram message text and SQL statements
• Flame chart / whole-test-flow text — span names, activity sources, boundary marker URLs
• Failure stack traces (3.0.72+), deep only on purpose: frame tokens like namespaces and file paths are too common for the instant filter, but filtering by a method or class name still reveals the failed scenario

Deep filtering runs automatically for any query with a text term of 3+ characters: shallow results apply at once. For the filter field, a small chip inside the field says "matching payloads & diagrams…" while it reads ("searching payloads & diagrams…" before 5.9.1; 5.11.0 had no field) and then what it added: "+N more found in payloads & diagrams" (or "no additional matches"). For a search, a thin bar runs along the top of the Search tab's results while it reads, and its Diagrams and Errors counts carry "…" (5.11.0). The results it adds join after those already listed, so a page being read changes at its end; the next search, sort or page puts every result in its place. The search and the filter field each have a deep pass of their own, and neither stops the other. A run whose words are the ones its pass read last is not read again (5.27.2). The pass reads a query's words apart from the tag: and status: that narrow the whole of it (outside every bracket of a query with no || outside them), which are tested on each scenario as the instant filter tests them, so a row of the Search tab's sidebar, put on or taken off, leaves the words as they were, and so do a dep: typed after them and the same query run again by Back, Forward or Enter. What the pass found stays found, and a pass still reading goes on. Until 5.27.2 each such run read the query afresh, and every result only deep filtering finds dropped out until it answered, so a click on a row emptied the Search tab and filled it again. Positive queries only ever add results: a scenario the instant filter already shows is never taken away. Only for negated queries (!!) is deep filtering authoritative and able to remove results (the full corpus can newly match the negated term); the chip then read "results refined (+N/−M)". Matching is against the text as captured: the line breaks Kronikol writes into a note body to keep the diagram inside its width budget are normalized away, so a long token or URL the diagram displays across several lines is still found as one string.

Since 3.0.86 that undo is exact rather than a guess. It keys on the marker the generator writes at each break it inserts; before then it rejoined any note line that did not start with whitespace, which was right for indented JSON and wrong for a plain-text or SQL payload whose real lines start at column 0 — those lost their line breaks in the index and could match across them. A payload's own newlines are now always preserved, and only Kronikol's own breaks are undone.

Since 3.30.1 the same goes for the characters Kronikol writes as code points to keep them from PlantUML (see Content Formatting): a payload's ', ! or ~ is indexed as captured. A query's own ~ is matched as typed.

From 5.11.0 the Search tab shows, for the results on the page shown, the lines where each one matched, a deep match's among them: the line of the payload, query, diagram or stack trace that holds it. Following a line goes to the match and marks it (below). Before, a deep match revealed only the scenario (or parameterized group) that contained the text, and finding which note, row or diagram matched was left to the browser's in-page find. kronikol query grep gives addressed results from the data file. Since 5.4.0 a payload longer than 40 body lines is drawn 40 lines tall with a scroll box that holds all of it (see A long payload scrolls in its box); going to a match in it scrolls the box to the words (5.11.0), and the in-page find reads the box once it is filled, which happens as its note comes within a window height of the window.

Deep filtering is on by default and adds roughly 0.25–1 MB to the report; set ReportConfigurationOptions.FullSearchIndex = false to opt out (see Report Configuration).

Before 5.5.4 deep filtering added nothing in WebKit, Safari's engine, for a report opened from disk: inside a worker WebKit refuses every read of a Blob on a file:// page, which is how the index worker read its index, so the index never loaded and the chip never came. Since 5.5.4 the worker reads its index another way, and deep filtering works in every engine.

Text that was truncated at capture time never reaches the report, so no filter can find it:

• SQL results are captured to 10 rows / 500 characters per value by default (MaxResponseRows / MaxValueDisplayLength on the SQL tracking options) — raise them for more text to filter by.
• RequestResponseLogger.MaxContentLength (off by default) cuts HTTP bodies when set.
• Assertion/closure values are captured to 100/50 characters.
• JSON properties whose value is null are stripped by the diagram formatter, except in a database call's note (since 4.19.6); elsewhere, filtering by "someField": null matches nothing even though the wire payload contained it.

To search the wire-exact captured data (nulls intact, original formatting, plus headers-as-data and numeric-aware matching), use kronikol query grep against the data file — see Querying Reports. Deep filtering answers "find it in the report you're looking at"; query grep answers "find it in what was captured".

If advanced mode meets a parse error (e.g. unmatched parentheses), it silently falls back to the legacy filter, which uses simple text matching with implicit AND.

From 5.11.0 the report has a search of its own, laid out after GitHub's: a search button, a query builder that takes the query, and a Search tab that lists what the query matched and takes you to each match. A search hides nothing: the Features list, the timeline and the components show what the filters leave showing, whatever is searched (from 5.12.0; in 5.11.0 a search also hid the scenarios it did not match, as a filter does).

The search button sits on the title line, left of the theme switch, and reads "Type / to search". Once a search is applied it shows the query, its qualifiers coloured, with a clear button beside it that empties the search and leaves the filters as they are. On a phone (768 px wide or less) it is a magnifier, shaded while a search is applied, and once the title line has scrolled out of view a floating search button above the back-to-top button opens the search from anywhere down the page. The Specifications report has it too; the labs page, which has nothing to search, does not.

The button, or / from anywhere but a field, opens the query builder over the page. It opens holding the applied query, all of it selected, so typing replaces it and an arrow key keeps it. / is left to the browser on an exported page, which has no search, and while an image, an internal-flow popup or the builder is open. As you type, the query's keys, values and operators are coloured, and a qualifier the search cannot read turns the field's edge amber.

Under the field it suggests, in this order:

• the search itself;
• inside a feature, the search in that feature alone (feature:"Pancakes Creation" pancake);
• up to five scenarios and then three features whose names hold every word typed, to jump to;
• the keys the word being typed starts: status:, tag:, dep:, feature:, duration:, is:happy;
• after a key's colon, its values with how many scenarios carry each: the statuses and this report's history verdicts, the tags and dependencies of the filter rows, the features, and this report's duration percentiles with their times.

Empty, it lists the searches run on this page since it opened (nothing is stored), the failed scenarios to jump to, and the keys.

Down and Up move through the suggestions; Enter runs the one chosen, or with none chosen runs the search; Tab completes a key or a value. Escape, Back or a click outside the builder closes it, drops what was typed and puts the focus on the search button. A scenario chosen to jump to opens on the Features tab, and the search stays as it was; one the filters hide opens on the note that says so. Search syntax tips at the builder's foot gives the forms of this page in short, and which parts of a scenario the search reads at once and which only once a word has three letters.

The search runs on Enter, once. Enter on an empty field clears the search. The page's link carries the search as search=; the field you type in is #search-input, and a script reads the search applied with search_query(). Until 5.12.0 the builder also had a Filter row that applied the query to the tab on screen, and on a phone a Filters button: filter controls inside the search, both gone. The filter field is #searchbar, as it was until 5.10.1, and its query is q=.

While a search is applied the report bar has a Search tab, last in the row, with the number of results on it. Running a search from the builder opens it, and clearing the search while it shows goes back to the tab the search was run from. Its results are every scenario the search matches, whatever the filters hide (from 5.12.0; in 5.11.0 they were the ones the Features list showed, with a note counting the ones the filters hid). While the Search tab shows, the filter box, the bar's Filters, its readout and Clear All are out of sight; they come back as they were on any other tab.

On the left:

• Show: Scenarios, or Features (the features holding a result), each with its count.
• Matched in: Names (a feature's or a scenario's name, a description, a rule, an endpoint, the tags, the example values), Steps, Diagrams (requests, responses, queries, messages and the whole-test flow) and Errors (an error message or a stack trace), each with the number of results that matched there. A click keeps those results; a second click shows them all again.
• Status, Tags and Dependencies narrow the search, as GitHub's sidebar does: a click writes status:failed, tag:smoke or dep:"Payment Service" into the search's query, and a second click takes it out. A row narrows the whole query, whatever operators it holds: a query with || outside its brackets goes in brackets first, as in (toast || waffle) status:failed, a legacy tag expression's and, or and not become &&, || and !!, and an operator the row would leave dangling goes with it, so a second click puts the query back. A row is on while its qualifier narrows the whole search, so one typed into the builder turns its row on too; one inside brackets or beside an || narrows only part of it, and leaves its row off. One result at a time: another of passed, failed, skipped and bypassed replaces the one on, and a history verdict such as status:flaky stays. A tag or a dependency that is off has an Exclude button (×) beside its count, shown while the row is hovered or holds the focus (always, on a screen that cannot hover), that writes -tag: or -dep:, leaving those scenarios out of the search; a row that is on, or leaves its scenarios out, is taken out by a click anywhere on it (until 5.12.1 the × stood over the count, and a click there left the scenarios out). Each row counts the results its click keeps: a dependency's counts the ones with a longer name it is inside too, as dep: matches one. The ten most frequent show, then More tags… or More dependencies…. The filter box is not touched (until 5.12.0 these rows were its own buttons and chips, and a row could stick on or off).
• Advanced: Feature, Tag, Dependency, Status and Duration write their key into the search and open the builder at its values; Happy paths adds is:happy and runs the search. Last, Search syntax tips.

On the right are the number of results and the time the search took; the sort, Best match (the default), Report order, Name, Longest first, Shortest first or Failed first; and a ⋯ menu with Search syntax tips, Export results as HTML and Export results as CSV, which write out the search's results whatever the filters show, and whatever Show and Matched in choose (5.11.0 wrote out what the Features list showed). Ten results a page, with Previous, the pages and Next under them. Best match ranks a result by where each word matched, its name first, then its tags, then its steps and its error, then the rest, a tie keeping the report's order. Longest first and Shortest first read the scenario's own time, as duration: does, and Failed first puts the failed scenarios first, then the skipped.

A result shows its status, its feature (a link to the feature), its name and its own time; its tags, Happy path, and for an outline how many of its rows match; then up to three lines where it matched, each with its kind (NAME, FEATURE, DESCRIPTION, ENDPOINT, RULE, TAGS, EXAMPLE, STEP, ERROR, DIAGRAM, FLOW) and the matched words marked. "Show N more matches" shows up to 20. A line is the line holding the match as written, cut to 160 characters around it. The lines from payloads, queries, diagrams and stack traces come from deep filtering, for the results on the page shown. A diagram's participants and call paths that only the instant search has read (a word under three letters, a report written with FullSearchIndex off, or before deep filtering answers) show as the search reads them, in lower case. Under Features, a feature shows how many of its scenarios match, and the first five of them.

A qualifier the search cannot read is searched as text, and a line over the results says why (above). While deep filtering reads, a thin bar runs along the top of the results (above). On the Search tab Down and Up scroll the page, where on the Features tab they move between scenarios.

On a phone the results take one column. The sidebar and the sort give way to a button naming what is shown, with its count, whose menu holds Scenarios, Features and the four places of Matched in, beside the ⋯ menu. On a phone the search is narrowed in the builder, whose keys and values carry their counts.

A result's title, or any of its lines, takes you to the match itself: the Features tab, the scenario opened, its outline row chosen, and then its steps opened (each composite step on the way too, its sub-steps drawn), its failure opened, its example's cell opened or a long value shown. A result the filters hide opens on the line that says so, where the scenario would be, and the way waits there: the line's button clears the filters, shows the scenario and goes on to the match (5.12.0). For a match in a diagram:

• the diagram's view is chosen (Sequence, Activity or Flame) and the diagram drawn, or the part of a long diagram that holds the match;
• whatever hid the match is turned on, for that scenario alone: Databases, Events, Assertions, Steps, Setup or Headers;
• a note is expanded only when the words are past its cut, and a note shown as YAML is shown as JSON only when the words are in its JSON alone;
• a long note's scroll box is scrolled to the words;
• words drawn under 10 px, as in a wide diagram shrunk to fit, are zoomed with the diagram's zoom slider until they read at 10 px;
• for a diagram drawn as a picture by a PlantUML server or a local engine, its Raw PlantUML section is opened and the words marked in its text.

The matched words are marked where they are drawn, on the --kron-mark colour with a --kron-mark-edge underline (Report Themes), and their place (a note, an arrow's label, a step, the error) is outlined in the accent colour, which pulses twice as you arrive (not under reduced motion). The focus goes to the place. A line under the diagram's view tabs says what was changed, such as "Turned on to show this match: Databases. The note is expanded.", and the status line a screen reader reads says where the match is and what was done: "Match in the response body of GET: /pantry, in the diagram. Databases turned on, the note expanded." Past 300 ms it says "Opening the match…" first. When the words are still not drawn after every step, because the diagram does not draw that part of its source, the page goes as far as it can and both lines say "This match is in the diagram’s source, in a part the diagram does not draw."

What was turned on or opened stays so for that scenario; the rest of the report keeps its own settings. The marks, and the line under the view tabs, go when you move on: Escape (when no builder, image or popup is open and the focus is not in the filter box), another search, a click outside the scenario, a filter that hides it, or closing or leaving it. A copy of the diagram and an export of the page carry no marks. A scroll, a key or a click of yours, or Back or Forward, stops the way to the match wherever it has got to.

The address keeps the match as hit=, after the scenario's anchor, so Back returns to the results on their page and sort, scrolled where they were, the title or line you followed focused, and Forward, a reload or a shared link goes to the match again. A hit= that no longer fits the report, such as one opened on another run's report, opens the scenario, and the status line says "This match was not found in this report; its scenario is shown."

Each is written only where it says something the link would not say without it, as tab= and view= are (Generated Reports › Deep links).