# Verify a deploy with your agent

Have your agent judge a production deploy, check that the fixes it shipped held and confirm a new service reports everything.

A fix is done when production stops raising the error, not when the pull request merges. Unhandled gives your agent three checks. Each reads data Unhandled already holds, so none needs the dashboard.

## Check that a deploy is healthy

Ask the agent "is the latest deploy healthy?". It calls `list_deployments`, takes the newest match, then `get_deployment` with `impact` and `issues`. The verdict decides what it reports.

| Verdict | What the agent says |
| --- | --- |
| `pending` or `preliminary` | Too early. What is known so far, and that the final verdict lands an hour after the deploy |
| `healthy` | Healthy, with the evidence |
| `faulty` | The regressed endpoints and the new or regressed issues of the version |
| `inconclusive` | Too little traffic. It does not call the deploy healthy |

A deploy the agent cannot find means CI did not declare it. [Deployments](/docs/features/deployments#declared-deployments) shows how `unhandled deploy` declares one, and [Faulty deploys](/docs/features/deployments#faulty-deploys) lists the thresholds behind the verdict.

## Check that a fix held

Link every fix to its issue so Unhandled knows which deploy carries it. End the fixing commit with a `Fixes-Unhandled: <issue ID>` trailer, or call `link_pull_request` with the pull request URL. The issue resolves in the first production deploy [declared with its commits](/docs/features/deployments#commits) that carries the fix. [Fixes](/docs/features/issues#fixes) has every source.

Then call `verify_fix` for the issue. It answers one of these, with the counts before and after and the entry point's exposure:

| Answer | Meaning |
| --- | --- |
| `fixed` | No event on the fixed version or a later one, and it served enough requests |
| `not_yet_observed` | Not enough traffic to tell. Ask again later |
| `still_failing` | The issue occurred again on the fixed version or a later one |

Unhandled also runs the check on its own every minute and records the result as **Verified fixed**, **Fix did not hold**, or one of two unverified states. [Fix verification](/docs/features/issues#fix-verification) has the rules, and [versioned webhooks](/docs/features/notifications#versioned-events-for-agents) get `fix.verified` and `fix.failed`.

## Check that a service reports everything

After instrumenting a service, call `verify_setup` with the service and environment. It returns a checklist for the key, traces, logs, exceptions, environment, user ids, release, source maps, deploys and their commits. Each failing check has a `nextStep` and a link to the page that explains it. The agent works through them until none fails.

## With the Claude Code plugin

`/unhandled:verify-deploy [version or SHA]` runs the first two checks in order and offers to fix any new or regressed issue with `/unhandled:fix-production-error`. It rolls back, resolves and reopens nothing unless you ask. See [Set up with Claude Code](/docs/agents/setup-with-claude-code).