Upstate
Deployment receipts
Kamal reports that a deployment ran. Upstate independently checks what appeared on the hosts and whether the required health signals stayed ready. A receipt brings those facts and timestamps together.
Open a receipt
Open the latest deployment from your project, or use the CLI in a connected repository:
upstate receipt
upstate receipt --watchThe watch command waits for a result while verification proceeds. Finishing kamal deploy does not itself mean Upstate has verified the deployment.
Understand the verdict
| State | Meaning |
|---|---|
| Verifying | Upstate is still collecting and evaluating evidence. |
| Verified | Deployment start and completion were reported, intended runtime appeared, and required health stayed ready through stabilization. |
| Needs attention | Fresh evidence indicates a mismatch, unhealthy runtime, or unstable required health after the evaluation window. |
| Incomplete | Completion or enough fresh independent evidence did not arrive before the deadline. |
| Superseded | A newer deployment replaced an unresolved verification. |
Normal observer reporting is about once a minute. Runtime readiness must stabilize for sixty seconds. Configured HTTP and probe signals need fresh consecutive successes. A configured check that fails is different from a check that was never configured.
Fresh evidence of a problem can produce a needs-attention result after five minutes. Missing completion or insufficient evidence can produce an incomplete result after thirty minutes. Read the receipt's specific attention items rather than interpreting incomplete as a confirmed application failure.
Read the evidence
Review the intended version, role and host coverage, report times, health signals, and lifecycle timeline. Targeted deployments are evaluated against their intended targets; other roles can legitimately remain on another version.
The terminal verdict keeps the evidence used to reach that conclusion. Later runtime changes appear as current diagnostics and activity rather than rewriting the original verdict.
Where available, a separate summary compares measured windows before and after verification. Check sample counts and partial or unavailable readings before interpreting a change. These measurements do not prove that a deployment caused the difference.
See what happened after the deploy
When the app gets traffic through kamal-proxy, the receipt gains an After the deploy section about 15 minutes after the deploy finishes. It compares errors and response time before and after, and warns if either got clearly worse. With too little traffic it says so instead of guessing. See App health and Rails.
Investigate an unexpected result
For missing evidence, confirm the deploy hooks ran and the observer is reporting. For a version mismatch, compare the intended targets with the reported instances. For unhealthy HTTP checks, investigate the URL and runtime behind that check.
Upstate shows evidence and suggested next steps. It does not roll back or modify your servers.