Run Detail

The run detail page is a v2 command centre with four tabs — Overview, Cases, Issues, and Activity. A linear breadcrumb header names the project, Test Runs and the run itself — its reference (TR-12) followed by its name — above the editable title, meta chips, and the close / reopen actions. Press Esc or click the back arrow to return to the list.

When the run will not open

If the run cannot be loaded, the page says which kind of problem it is and stops, rather than sitting on a spinner. There are three of these, and only one of them is worth retrying.

A connection wobble is retried for you first. The page makes up to three attempts before showing Could not load. A definitive answer from the server — deleted, forbidden, or a malformed link — is not retried at all, so those two states appear immediately.

An already-loaded run stays on screen. If a background refresh fails while you are working, the run you are looking at is kept rather than replaced by an error page.

Being denied the View test runs permission outright is a different screen again, and reads You do not have permission to view this run.

Think of it as mission control

The header is the status board — the run’s name, progress bar, and the close / reopen actions. Overview is the health dashboard. Cases is where testers execute — inline result buttons, a side panel, a full-screen focus runner, or the per-case runner route. Issues answers two questions side by side — what broke (Defects) and what the run was meant to prove (Requirements). Activity is the day-by-day commentary feed.

Header

• Breadcrumb — a linear crumb from the project, through Test Runs, ending in the run’s reference and name (TR-12 Regression — Checkout) with its ··· menu. The reference is unique within the project and is the string to quote in a ticket or a chat message; you can paste it straight back into the run search. It is not the number in the page’s web address. A run created a moment ago shows its name alone until the server assigns the reference. When you arrived from the run list, the crumb also carries an n / N position stepper that walks that list; open a run by direct link and there is no list order to walk, so no stepper appears. The ··· menu on the terminal crumb is the single home for run actions — there is no separate title-row actions menu. On an open run it holds Edit run…, Re-run failed & blocked, Close run…, Duplicate run, and Delete run…. Edit run… is how you change which cases are in the run, and its tags: it leaves this page for the test case repository and reopens the Run Composer against this run, where the name, cycle, environment, tags, and cases are edited together. See Editing a run. On a closed run, Edit run and Close drop out and Reopen run takes Close’s place, alongside Re-run failed & blocked, Duplicate run, and Delete run… These run actions need the Create test runs permission; Delete needs Delete test runs.
• Title — editable inline when you have Create test runs permission (read-only on a closed run).
• Meta chips — workflow state, cycle link, environment, tags, contributor avatars, and percent executed.
• Progress bar — segmented status distribution with completed-out-of-total count, shown in the tab strip.
• Tabs — Overview, Cases, Issues and Activity, underlined when selected. Cases shows how many cases the run holds. From the keyboard, Tab onto the strip, then ← / → move between them and Home / End jump to the first and last tab.

Closing and reopening a run. There is a single Close run… action, and it lives only in the crumb ··· menu — there is no duplicate title-row Close button and no separate “Mark completed”. Closing is server-guarded (never optimistic): if any case failed without a linked defect the close guard prompts first, and the close freezes a sign-off snapshot. A closed run shows a read-only banner across the header, carrying a Reopen run button for users with the Create test runs permission. See Managing Runs.

Overview tab

The default tab. A two-column layout summarises run health and metadata.

Cases tab

The primary execution workspace. Lists every test case in the run with its current result, assignee, and folder path.

When issues are linked to the run itself rather than to a case, one line above the list says so — 2 issues on the whole run · DEV-5 DEV-7 — with each key as a link to its tracker and View in Issues ›, which opens the Issues tab with those rows expanded. Open a case in the per-case runner to attach them to it; the line disappears once nothing is left on the run.

Each case row’s issue chip names this run’s defect first. A known issue — a Defect linked on the test case, not in this run — gets a dashed chip of its own, so it reads differently from the run’s defects; its hover card says on the test case · not counted in this run. A Related link’s card says Related, and grouped by Linked issue, a Related issue’s group header is tagged Related, never Defect.

Toolbar

The toolbar is split into a left scope cluster and a right controls cluster:

• Folder jumper — scope the list to one of the run’s own folders (or Ungrouped) without leaving the page. All cases clears the scope.
• Quick-filter chips — All, Untested, Failed · Blocked, and Mine (cases assigned to you). Each chip shows a live count. While the run has more cases than are loaded, the counts cover the loaded ones and say so (of 100 loaded); as soon as anything narrows the list, the rest of the run is loaded (up to 500 cases) and the counts cover the whole run. Until the first page of cases arrives, the chips and the folder jumper show a placeholder bar where the count goes, never a 0.
• Search — filter cases by title within the run. Press Enter to apply; the search runs on the server and refetches.
• Filter — opens a two-pane fly-out with multi-select property filters (keyboard shortcut f). The field pane has a type-to-find box and splits into Built-in and Custom fields sections. Active selections appear as removable chips in a rail below the toolbar.
• Display — a popover that leads with the list / table / board view control, then grouping (Folder — the default — Tester, Status, Linked issue, Requirement (covers), or no grouping) and ordering (Run order — the default — Status, Case ID, or Title, with an ascending/descending toggle). The grouping and ordering menus are admin-driven: each of your workspace’s enabled single-select custom fields (for example Priority or Severity) is appended as its own grouping and ordering option, in the admin-defined field order; past ten entries they gain a type-to-find box. In list view it adds a Result entry control (Inline or Panel); for list and board it also exposes display-property chips to show or hide trailing fields. The chips are split into two sections: Built-in — State, Folder, Template, Labels, Requirements, Linked issues, Updated, Result, Tester, and Executions, of which only Linked issues, Tester and Executions are on by default — and Custom fields, one chip per enabled run-relevant custom property field, in admin order. Long-form TEXT fields are not offered here — a paragraph cannot be a trailing chip — they render as prose blocks on the case instead. Newly enabled custom fields are shown by default. When an admin disables a field it drops out of the popover automatically, and any grouping, ordering, or chip preference that referenced it falls back to a default. Every option is a client-side view preference.
• Views — list is the fast execution stream, board renders one column per active Display grouping (Folder by default), and table adds a column manager in its header for choosing and ordering columns (in table view the Display popover points you there). In every view, clicking a case — a list row, a table row or a board card — opens it in the per-case runner, except in list view with Result entry set to Panel, where it opens the side panel. The row’s own controls (checkbox, result buttons, assignee picker, ··· menu) act without opening the case, and a focused row or card opens with Enter or Space.
• Focus — opens a full-screen, keyboard-first runner for one case at a time.

Case property filters

Click the filter button to open the fly-out. Options are derived from the cases already loaded in the run — only values that exist in the run appear. Selections combine with AND across fields and OR within a field, and apply instantly.

The fly-out lists seven built-in facets:

The last two are different in kind from the rest: their values are the tracker issues themselves, listed by key and title with the issue’s own status glyph, rather than a fixed vocabulary read off the rows. Pick one to narrow the run to just the cases touching it.

“No linked issue” and “No requirement” are separate questions, not opposites. A case can carry both kinds of link, one, or neither, and the same ticket can be linked to a case as a defect and as a requirement. So a case can legitimately appear under a Requirements value while also matching No linked issue — it covers something, but nothing broke on it.

Below them, a Custom fields section adds one facet per enabled option-typed custom field your administrator defined — dropdown, multi-select, and checkbox fields (for example Priority, Severity, or Automation). Free-text, date, number, and link fields are display-only and are not offered as facets, because their values do not form a finite checklist.

• Values are the options actually present on the run’s loaded cases, listed in the admin-defined option order.
• A multi-select field contributes every selected option, and a case matches if it carries any of the values you tick.
• If a field is later disabled, its facet simply disappears and a filter that referenced it stops narrowing the list rather than breaking it.

A case shows a field only if its template carries it. The run follows the same rule as the Cases page: a value stored in a field the case’s template does not carry is hidden. That case shows no chip, glyph or cell value for the field on its row, card or table row; the field filter does not count the value, so the case does not match it; and grouped by that field, the case sits under Ungrouped. In the table the cell is blank, with no picker, while a field the template does carry but the case leaves empty shows —. While the templates are still being read the cell stays blank, so it never flashes a dash first. The same case reads the same way here and in the Test Cases table. Result fields are not affected — they belong to the execution, not to the case’s template.

Grouping by linked issue or requirement

Grouping by Linked issue or Requirement works differently from grouping by Folder or Tester, because a case can have several of each. A case covering two requirements appears under both — that is the point: the group answers “what is the state of everything touching this ticket?”, and a case that touches two tickets is genuinely part of both stories.

• Each group header counts its own rows, so the group counts deliberately add up to more than the number of cases in the run. The toolbar’s N cases always shows the true distinct count.
• Keyboard navigation, select all, and the panel/focus running order all visit each case once, in reading order, however many groups it appears in. You will not be walked through the same case twice.
• Cases with nothing linked collect in a trailing group — No linked issue or No requirement covered.

The grouped value is not repeated on the rows

When the list or board is grouped, the group header becomes the only place that value is shown, and it drops off every row and card beneath it. Grouped by Folder, no row shows a folder chip; grouped by a custom field, none shows that field’s chip. It removes a column of identical text from every row in the group and leaves the chips that actually vary.

Three refinements are worth knowing:

• Grouped by Linked issue or Requirement (covers), only that ticket key leaves the chip — other linked issues still show, and the two relations are treated separately, so a case that covers the same ticket it is grouped under as a defect keeps its Requirements chip.
• Grouped by Status, only the opt-in Result label chip is hidden. The leading result glyph and the right-hand quick strip stay put — those are how you record a result, not decoration.
• Grouped by Tester, nothing is hidden. The tester slot is the assign picker, and removing it would take away the only way to reassign from that view. The rule dedupes a displayed value; it never removes a control.

Table view is the deliberate exception — cells keep the value. A blanked cell is indistinguishable from the em dash a genuinely empty one draws, and the column stays there either way, so hiding it would trade a harmless repetition for a real ambiguity and free no space at all.

On the board a suppressed chip is never drawn, so it does not eat into a card’s two-line chip budget or its +N count — the freed slot goes to something that differs between cards. All of this is display-only: your display-property choices are untouched, and turning grouping off brings every chip straight back.

Table columns

In table view, the header’s column manager chooses which field columns are shown and in what order (ID and Title are fixed). The shown list reorders with the up/down controls and hides with the ✕; the available list below is split into Available · built-in (Result, Tester, Folder, Template, Labels, Linked issues, Requirements, Updated) and Custom fields — one column per enabled custom property field, in admin order. A long template name in the Template column is cut short with an ellipsis; hover it for the full name. Long-form TEXT fields are excluded: at column width they would be blank or an ellipsis, so they render as prose blocks on the case instead. Past twelve columns the available list gains a type-to-find box. Option-typed custom-field columns also sort from their header. Default columns are Result, Tester, Folder, and Linked issues; a saved column that points at a since-disabled field — or at a TEXT field — is dropped automatically. The custom-field columns on offer come from the project’s whole list of display fields, not from the cases on screen, so a column stays available even when no loaded case’s template carries it. While that list is still loading, hiding, moving or adding a column keeps every saved column, including ones not drawn yet; a saved column is dropped only once the list has loaded without its field. Date fields read as Nov 2, 2026 in cells and chips, as they do on Test Cases. Requirements is available but off by default, so teams not doing coverage tracing do not pay for a column they never use.

The Linked issues and Requirements columns are two halves of the same information, split by what the link means: Linked issues shows defects and unclassified links, Requirements shows what the case covers. Each renders the first key with a +N for the rest, and the count always matches the keys behind it. The same ticket can legitimately show in both columns when it is linked to the case under two relations.

The table is the same grid as the Test Cases table, in one scroll box. ID and Title form a frozen block that stays put while the other columns scroll sideways, and the header row — and, when grouped, each group’s header beneath it — stays pinned as you scroll down. Drag the divider at the right edge of the frozen block to resize it, between 240px and 680px; tab to it and ← / → resize in 16px steps. Its width is remembered in your browser and kept separate from the Test Cases table’s, so resizing one never resizes the other. The other columns are not resizable here.

However far you scroll a wide table sideways, the column manager button stays pinned to the right edge of the header rather than scrolling out of reach.

Execution

• Inline result buttons — tap a status button on any row to record that outcome instantly. The UI updates immediately and syncs in the background (see Background saves).
• Panel mode — set Result entry to Panel in the Display control, then click a row (or press Enter) to open a side detail panel with the case’s steps, a rich-text result note, the result buttons, and result history.
• Focus mode — the toolbar Focus button (or F on an active row) opens a full-screen, keyboard-first runner. See Recording Results.
• Per-case runner — open a single case in its own route for step-by-step execution with prev/next navigation. See Recording Results.
• Assignee picker — change who owns a case directly on the row.
• Multi-select + bulk bar — select cases to open a floating bar at the bottom of the viewport with an accent N cases chip (clear with the inline ✕ or Esc), then Assign or Set result menus to stamp one assignee or one status across the selection (Set result also offers Clear result), plus a Remove from run action that takes the cases out of the run while preserving their result history. See Recording Results.
• Fail→issue prompt — when you mark a case Failed or Blocked and it has no linked tracker issue, a non-blocking prompt offers to raise or link an issue. Dismiss it twice in a row and the per-case prompting stops, replaced by a single standing N failures with no linked issue chip. See Recording Results.

On a closed run the whole Cases tab is read-only: no inline result strip, no assignee picker, no selection checkboxes, and no Focus action. Reopen the run to record again — see Reopening a run.

Cases load in pages of 100, and in list, table and board alike the next page loads as you scroll near the bottom — there is no Load more button. Loading more cases… shows while a page arrives; if one fails, the line reads Couldn’t load more cases · Retry, and it is not asked for again until you click Retry. Once anything narrows the list — a quick-filter chip other than All, the folder scope or a property filter — the tab loads the rest of the run by itself, up to 500 cases, and shows Loading the rest of the run… while it does; past 500, scrolling carries on from there. A narrowed view with too few matches to scroll continues when you turn the mouse wheel down over it. Switching between list, table and board keeps your scroll position. While the first page loads the tab shows placeholder rows rather than a spinner, and if it cannot be read it says Couldn’t load this run’s cases. with Retry instead of claiming the run is empty. The folder scope, quick filters, property filters, grouping, and ordering are all client-side over the loaded rows (no refetch); only the title search refetches from the server. See Recording Results for execution details.

Issues tab

Two questions, two scopes, chosen with the toggle at the top of the tab:

• Defects — what broke while running. Tracker issues linked from this run’s results, deduped by issue key and ranked open-first. This is the default scope.
• Requirements — what the run’s cases exist to verify. Tickets linked to those cases with a Covers requirement relation, each with the cases covering it and a coverage verdict. See Requirements view.

Each segment carries a live count (a scope with none shows no number), and ← / → switch between them once the toggle has focus.

While the tab reads its issues, Defects and Requirements each show placeholder rows under their real table header, with a bar where the summary line goes. The empty messages — No issues linked to this run, Nothing to triage, No requirements covered — appear only once the read has finished, and a read that fails says so with Retry instead.

Only Defect links are defects. The Defects scope lists links whose link type means Defect. A Related link (a General link type, such as Relates to) is never listed or counted as a defect: it shows on the case’s Issues list and on its Cases-tab chip, tagged Related. See Link types.

Defects

Every tracker issue linked anywhere in this run — from any tracker your project uses (Linear, Jira, GitHub, Azure DevOps, GitLab, Notion or a custom tracker) — one row per issue, open issues first. Failed and blocked cases surface here alongside issues raised from the fail→issue prompt.

Three places a defect can come from. A link on the run itself, a link on a result in this run (a case linked while running), and a link on the test case in the repository. Only the first two are this run’s defects. A Defect linked on the test case shows in every run that contains the case, because testers should see a known bug before they run — so it is listed here too, after the run’s own defects, as a Known · from case row: an outlined tag in the In this run column and a muted title. Known rows follow the All / Open / Resolved filter and expand to show their cases, but they are never counted: the summary reads 2 issues · 2 open · 2 cases affected · 1 known, and a run that has not started reads No issues found in this run · 2 known, never “2 defects”. Fail or block a case and Link the known issue to it, and it becomes a normal row of this run.

• Needs-triage strip — when any failed or blocked case has no linked tracker issue, a standing queue appears at the top listing each case with a Link issue action (attach an existing tracker issue) and a + New issue action. The strip disappears once every red result is triaged. Only a link made in this run counts: a known issue linked on the test case does not triage a red case — link it from the case’s Issues list, or with Link issue here, which links the case’s result in this run. Results for cases deleted from the repository after the run closed stay in the run as history, but those cases can’t be linked to issues: linking one says This case was deleted — link the issue to the run instead and offers Link to the run, which links the same issue to the run in one click.
• Lifecycle facet — All, Open, or Resolved (with open/resolved counts).
• The table — four columns: Issue, In this run, Status and Owner. Each issue is a group row, and the cases of this run linked to it are rows beneath it. There is no Tracker column: the tracker’s logo leads the key. When your project has two trackers of the same kind (say Jira · acme and Jira · payments), a small tag after the logo says which one.
• The key is the link. GitHub and GitLab keys always read with a hash — #18, never 18 — on every run surface. Click an issue’s key (logo and key together) to open it in its tracker in a new tab. It never expands the row, and it keeps its own tab stop, so a keyboard user can open the tracker without expanding anything. A row still syncing (···) or whose create failed has no key yet, so there is nothing to open.
• Hover card. Hover or focus a key for a moment and a card shows what is stored about the issue: its title, who it is assigned to, its status with the date it was last read (as of 2h ago), and what it means in this run (blocks 2 in this run, linked to the run, on the test case · not counted in this run). It is the stored reading, not a live fetch, and it closes when you move away, press Esc, scroll or click. For a link-only tracker it says Linked without details and why. On a touch screen there is no card: a tap opens the tracker.
• In this run — one chip: blocks N (red cases in this run), N cases, Re-test N (the tracker says fixed but red cases remain), Verified (fixed and every linked case passed), or a dashed Run chip for an issue linked to the run itself rather than to a case in it. A +N reach chip appears when the same issue is linked from other runs, with the run name on hover.
• Status — the tracker’s status as last read, with its glyph. Hover it for Last read from Jira 2h ago. A link-only tracker reads No details (the reason is in the tooltip); a tracker that can be read but has not been yet reads no tracker status.
• Expand any number of rows. Rows open and close smoothly, several at a time, and stay open when you switch between Defects and Requirements. A collapsed row’s links are not in the tab order. With reduced motion turned on in your operating system, rows open without animation.

Issues linked to the run itself

Some problems are about the run, not a case — a broken build, an outage, blocked test data. Pick Run only in the composer and the issue is linked to the run. Its row reads Run, never 0 cases. Expand it to see Linked to the run itself, not to a case in it and an Attach to row of the run’s failing cases: pick cases and click Attach to move the link onto them in one step — the run link is replaced, so the issue is never counted twice. A toast confirms DEV-5 linked to C-319 with Undo, which puts the issue back on the run.

Creating issues. + New issue opens an in-place composer. The Tracker menu lists every tracker with its logo and how it creates:

• Creates instantly — Linear, and GitHub once an admin’s connection test finds a token that can write issues. Create issue posts the draft and a row appears at once while the tracker assigns the key (shown as ··· until synced).
• Create there, then link — trackers with a new-issue form, such as Jira. Two numbered steps: 1 Create in Jira opens the tracker’s form with your title filled in; 2 Find it here — when you come back to the tab, a searchable tracker is searched for the title and the new issue is marked Just created. Trackers that can only be looked up by key, or only linked, ask you to paste the key or link.
• Link an existing key — trackers with no form: find the issue by search, key or link.

The composer opens on the tracker you last created an issue in on this project, else the one you use most. Link failing cases chips pick the cases to link; Run only (on when no case is picked) links the issue to the run, and the button says so — Create for the run / Link to the run. A run link is always a defect: the footer reads Links as Defect, whatever order your workspace lists its link types in. An issue already on the run or on other cases can still be picked, and says what will happen — On the run · attaches to C-319, Adds C-322; it is only marked Linked when every picked case already has it. Creating or linking requires the Manage external references permission.

A create the tracker rejects never disappears. If the tracker refuses the create — a validation error, a rate limit, an outage — the row stays on the list instead of vanishing, so you are never left believing a defect was filed when none exists. It shows failed in red where the issue key would be, reads Create failed — not in <tracker> when expanded, and carries a Retry create action on the row and in the expansion that replays your original draft. When the tracker is disconnected the row names it — Jira · acme is disconnected — reconnect it in Admin › Integrations — because a retry cannot win until it is reconnected. The retained row survives a refresh of the issue list and a full page reload — it is kept in this browser, scoped to this workspace, project, and run, for up to seven days — so closing the tab does not quietly discard the obligation. A successful retry clears it, and signing out clears every retained row from that browser, since the drafts hold text you wrote. A link the tracker refuses is not kept: it is removed and a toast says why.

Click a case under an issue — in Defects or Requirements — and the Cases tab opens on that case, in whichever view you use: the row (or board card) becomes the active one, scrolls to the middle of the list and briefly highlights; in list view with Result entry set to Panel, its side panel opens too. A case that has not loaded yet is fetched first, behind a placeholder row. If it cannot be shown in the list — hidden by the view, beyond the first 500 cases loaded, or the list could not be read — it opens in the per-case runner, and leaving the runner returns you to the Cases tab. A case no longer in the run keeps you on Issues with a toast: C-368 is no longer in this run. Linked defects also appear on the parent cycle’s Issues tab.

Requirements view

The same table as Defects, with three columns: Requirement, Coverage and Status. One row per requirement ticket the run’s cases cover: the tracker’s logo and key (the key opens the tracker, with the same hover card), its title, and the number of covering cases. Coverage shows a pass ring, n/N passed in this run, and the verdict. Expand any number of rows to see which cases cover each requirement and how each of them ended. A requirement in a link-only tracker reads No details.

The verdict is derived from results in this run only — a pass the same case earned in a different run is never borrowed, because a requirement is only verified by the testing you actually did here. The four verdicts are shared with the cycle Issues tab, so Cycles and Runs can never say different words about the same requirement:

“Success” and “failure” here are the flags your administrator set on each status, not its name — a custom status called Passed w/ exceptions verifies a requirement, and one called Env down puts it at risk. See Status Properties.

Requirement links are read-only in a run — the summary line says read-only — set on the test case: coverage is authored on the test case, so there is nothing here to add or remove. Read-only means it can’t be changed, not that it can’t be opened: the key still opens the tracker. Link a requirement from the case itself — see Link types.

Requirement coverage (Overview card)

The Overview tab summarises the same data in one card: <n> of <total> requirements verified, a percentage, and a bar split into Verified, At risk, and Not verified yet.

The denominator is the requirements this run’s cases link to — not the number of cases, and not every requirement in the project. A run that covers three tickets is measured against three, however many cases do the covering.

• If links exist but none are classified as coverage, the card reads 0 of 0 requirements verified with No relation set, so nothing counts as coverage yet — with no action button. To find the links, turn on the Requirements display property on the Cases tab: each affected row shows an N unclassified chip. A link’s relation is changed on the test case, not in the run. That honesty is deliberate — unclassified links are not quietly counted as coverage.
• The card does not render at all while its data is still loading or unavailable, rather than showing a provisional number. A card is an assertion.
• When there is nothing to say — no requirements and no unclassified links — it stays hidden.

Activity tab

A day-grouped feed of run events — result recordings, case reassignments, run metadata edits, and run close / reopen events. Each day header shows how many events occurred that day. A 7d / 14d / 30d range toggle (default 14d) scopes the recent-change summary; older events load on demand with Load more.

Closing and reopening a run are recorded here as their own rows attributed to the person who did it: … closed this run — signed off & snapshot captured, and … reopened this run for edits, each with the sign-off snapshot it captured or preserved. The wording carries the meaning on its own, so the rows read correctly without relying on their colour or icon.

Background saves. Result and assignment changes on the Cases tab apply to the UI immediately and persist behind you. A dot on the avatar at the foot of the sidebar shows a save in flight, and changes colour if one fails; when that happens your edit stays on screen and the toast offers Retry. See Background saves.

Your own edits show up right away. Recording results, reassigning cases, linking or raising issues, and run metadata edits refresh the Issues and Activity tabs as soon as you open them — no hard refresh needed. Changes made by other testers while you have the run open may still need a refresh to appear.