Slot metadata
A slot is more than its tracked ref. You can attach extra context that makes the board carry more weight at a glance.
Owner
A persistent owner is the team member responsible for a slot — separate from "last updated by" (which changes every time a webhook arrives) and separate from the reservation holder (which is time-bounded).
Set the owner on /<workspace>/settings/environments → Owner select.
Choices are gated to current workspace members; if an owner leaves the
workspace, the slot quietly shows "no owner" until you pick a new
one. The board card shows owner: @<name> under the slot title.
When to use it: long-lived staging envs that someone "owns" (the QA lead, the perf person, the integration partner). Less useful for ephemeral preview slots.
URL
The canonical URL of the env (https://staging-1.acme.test,
https://preview-pr-42.acme.test). Set it on the Environments page.
It surfaces on the board as a small "Open ↗" link below the slot
name.
The URL is distinct from currentUrl, which deploy webhooks may
populate with the URL of the current deploy (often a per-commit
preview URL). The persistent url is set by humans; currentUrl
shifts every deploy.
Health-check dot
A small green/amber/red dot next to "Open ↗" reflects our server's reachability of the URL — not the user's. It pings opportunistically on board renders (HEAD or GET, 4-second timeout) and caches per slot for 60 seconds. The dot meanings:
- 🟢 Green — reachable in the last 5 minutes (HTTP 2xx/3xx).
- 🟡 Amber — was reachable, but more than 30 minutes ago.
- 🔴 Red — failed in the last 5 minutes (4xx/5xx/network error).
- ⚪ Grey — internal address (loopback / private CIDR) was skipped, or no check has run yet.
Internal URLs (http://10.0.0.5, http://localhost, 192.168.x)
are deliberately not pinged — our server can't reach them and a
permanent red dot would be misleading. They show grey.
The dot is a heuristic. It doesn't replace a real uptime check; it's a "is the obvious thing obviously broken?" signal.
Note
A freeform short note the team uses to flag state ("QA-Bob owns this until Friday", "perf-test in progress", "broken — pinned for debugging"). Up to 280 chars, italicized below the slot's URL on the board card.
When to use it: ephemeral context that the owner field can't capture. Notes are not searchable; treat them like sticky notes, not metadata.
Tags
Workspace-scoped colored labels for soft categorisation:
perf-test, demo, broken, do-not-touch. Labels normalise to
lowercase hyphen-form ("Perf Test" → perf-test) so the same tag is
one row across slots.
Tags are added on the Environments page via a small input next to each slot's existing chips. The same tag re-used across slots keeps the same colour (color is hashed from the label).
When to use it: faceting the board. "Show me everything tagged
broken" doesn't exist yet (search is a future feature), but the
chips already make the board scannable.
What about a reservedNote?
A reservation can carry its own note ("QA branch for issue #123 until Tue"). That note lives on the reservation row, not the slot, and disappears when the reservation expires or is released. See Reservations.
Summary table
| Field | Where | Lifetime | Who sets it | |---|---|---|---| | Owner | Environments page | Persistent (until cleared) | Admin/owner | | URL | Environments page | Persistent (until cleared) | Admin/owner | | Health dot | Auto (60s cache) | Refreshes per render | Server probe | | Note | Environments page | Persistent (until cleared) | Admin/owner | | Tag | Environments page chip row | Persistent (until removed) | Any member | | Reserved note | Claim row on board | Bounded (with reservation) | Any member |