Releases
Read the Deploy Impact Report for the latest ship and decide what to investigate next.
Releases is the first place to open when the team asks, "Did the latest deploy hurt signup, checkout, traffic, or speed?"
What the page is for
In Callra V1, Releases is where each ship becomes a Deploy Impact Report.
Instead of treating each deploy as an isolated event forever, Callra groups nearby production deployments into one release group and then shows:
- verdict and confidence
- grouped deployment timeline
- top regression metric
- affected pages, routes, devices, and segments
- suspect commits and change range
- baseline evidence and recommended action
Read the report in three passes
1. Verdict
Start by answering:
- is the current production state healthy, watching, needs attention, or likely regressing?
- how strong is the evidence?
- what is the top issue?
2. Evidence
Then inspect the main support for that verdict:
- top regression metric
- affected pages and routes
- speed context
- grouped deploy timeline
- suspect commits
3. Next action
Finally decide what to do next:
- inspect one affected page or segment
- compare one suspect commit
- keep watching for more data
- continue into Impact Analysis
- prepare a rollback or hotfix if the evidence is strong enough
Recommended workflow
Create one manual release first if automation is not wired yet
You do not need provider webhooks on day one.
A manual release is enough to validate the workflow and prove that the next ship can be reviewed in Callra.
Use low-sample verdicts correctly
If the verdict says Not enough data, the page is still useful.
That means Callra can already show the deploy context and early evidence, but the current sample is too light for a strong conclusion.
The best next steps are:
- wait for more production traffic
- verify the shared script is live on the real page
- confirm Speed Insights is receiving samples
- check whether the release is simply too recent to judge confidently
What counts as strong evidence?
The strongest reports usually have all of these:
- enough traffic and speed samples
- explicit release attribution where available
- a clear before/after baseline
- one or more affected pages or routes
- one or more suspect commits or a tight grouped change range
Next step
- Need broader business context: Impact Analysis
- Need proactive follow-up: Reports and incidents
- Need CLI or MCP investigation: Agent, CLI, and MCP workflows