Status Properties
Every status has a fixed set of fields that control how it is identified, displayed, and interpreted. This page describes each property and how it affects behaviour across the platform.
Identity fields
System Name
A unique, immutable identifier for the status. It must be lowercase and may contain letters, numbers, and hyphens (e.g. passed, blocked-by-env). The system name is set at creation and cannot be changed afterwards. It is used internally and may be referenced by integrations, reports, and API consumers.
Choose the system name carefully. It is permanent. If you need a different identifier, you must create a new status.
Display Name
The human-readable label shown to users across the platform. Can be updated at any time without affecting the system name or historical data.
Aliases
Optional alternative names for the status. Aliases are used for search and matching — for example, when importing results from external tools that use different status terminology.
Visual properties
Base Color
A color used to represent the status throughout the UI — in result lists, charts, and badges. Choose a color that clearly communicates the status meaning at a glance (e.g., green for passed, red for failed).
Semantic flags
Semantic flags tell the platform what a status means. They drive aggregations, summary calculations, and pass/fail reporting.
| Flag | What it means |
|---|---|
| Considered Success | Results with this status count toward the success total in summaries and reports. |
| Considered Failure | Results with this status count toward the failure total. Typically used for failed, errored, or blocked statuses. |
| Considered Completed | Results with this status are treated as done — they count toward overall completion progress regardless of pass/fail outcome. |
A status can have multiple flags enabled simultaneously. For example, a Passed with Warnings status might be both Considered Success and Considered Completed.
Display Order
Controls the sort order of statuses in dropdowns and selection lists. Lower numbers appear first. If two statuses share the same display order, they are sorted alphabetically by display name.
System status
Some statuses are built into the platform and are marked as system statuses. System statuses cannot be deleted, though most can be disabled. They provide a stable baseline that the platform relies on for core functionality.
The Untested status is a special case among system statuses. It is the default state for every test case when a test run is created — meaning every result starts as Untested until an outcome is recorded. Because of this, Untested has additional protections beyond the standard system status rules:
- Cannot be disabled — the enable/disable toggle is locked.
- Semantic flags are locked — Considered Success, Failure, and Completed cannot be changed.
- Scope availability is locked — Untested is always available for all scopes.
- Project assignment is locked — Untested always applies to all projects.
- Can be customised — display name, aliases, and color can still be updated.