"Is it out?" is the question a PM asks most, and engineers ask it too. Until now the answer took two tools and a join done by hand: find the commit in the host's release log, then open LaunchDarkly to see whether the flag is on for anyone in production. The item page had a slot for the answer, and it stayed empty.
Now each environment's release step tells SLEDS one thing: this commit of this repo is now running here. SLEDS works out which PRs that commit carries, rolls them up to the items and epics they belong to, and reads the item's flag in that environment. SLEDS never deploys anything and never changes a flag. It records what it is told and reads what is there.
What you see
On an item's Release tab, Where it's live has one row per environment of the workspace, in order:
- Live for everyone: deployed, and the flag serves its on value to everyone there. An item that names no flag is live when it is deployed.
- Live for some: deployed, and the flag is on for targets, rules or a partial rollout.
- Deployed: the code is running there, but the flag is off, or could not be read. The row says which. It never says live when it cannot tell.
- Not deployed: not every PR on the item has reached that environment yet. The row counts them: 1 of 2 PRs deployed.
A row opens to its PRs, each with its state, when it got there, and the release link the deploy carried. An epic gets the same rows, counted over its children: production · 4 of 6 live · 1 deployed, flag off · 1 not deployed. A PR in the rail carries a small strip with a dot per environment.
Released now means one thing: deployed to the workspace's production environment. Merged is not released. The item tool in chat and in the console prints the same rows first, so "is SL-1760 out?" gets the same answer wherever it is asked.
Reporting a deploy
Set it up once in Settings › Deploys: name the environments and say which one is production, map each to the LaunchDarkly environment it reads flags from, and mint a deploy token. A token can only report deploys. The page has setup snippets for a Heroku release phase, a Vercel deploy hook and a GitHub Actions step. Each release step then runs one line:
sleds deploy --env productionThe CLI fills in the repo and the commit from git and reads the token from SLEDS_DEPLOY_TOKEN. In a monorepo where each app ships on its own, add --service web. A deploy SLEDS cannot match still answers 200, so a release step never fails because of SLEDS. Settings › Deploys lists it under recent deploys with the reason.
A PR counts as deployed when its merge commit is in the history of the commit the environment is at. If a deploy rolls an environment back, the PRs it left out go back to not deployed on their own. SLEDS may say Not deployed a little late. It never says Deployed early.
Day one
A record that starts on the day you turn it on would read Not deployed for everything already in flight. So when a workspace adds its first environment, SLEDS reads the last 90 days of merges on its repos. The first deploy you report finds that work already there, and it reads as deployed from the start.
Why it matters
An item's band is for the work. Done is when the work reaches the people it was for. With deploys on the record, an item that merged on Tuesday and reached production on Friday reads that way, and a PM can see it without asking anyone. Every deploy and every PR's timestamps are kept from this slice on, so lead time and deploy frequency can later be worked out over the whole history.