drn Post-Deploy Health Validation
Validate that a deploy that has just landed is healthy: confirm it actually shipped what was intended, then check CI, rollout, error tracking, and monitoring — correlating every finding's timing against the deploy's start so pre-existing issues are not mistaken for regressions.
Run this after the user confirms the deploy has finished (this skill does not poll or wait for a deploy in progress).
Arguments
$ARGUMENTS- Optional: the deployed branch/tag/ref, and/or a deploy start timestamp. If omitted, detect the deployed ref the same waydeploy-auditwould and derive the start time from the deploy pipeline itself in Step 2.
Context
- Remote: !
git remote get-url origin 2>/dev/null | head -1 - Default branch: !
git branch -r 2>/dev/null | grep -oE 'origin/(main|master)' | head -1 - Current HEAD: !
git rev-parse --short HEAD 2>/dev/null | head -1 - Latest tag: !
git describe --tags --abbrev=0 2>/dev/null | head -1
Instructions
Work through the following steps in order — the timestamp correlation in Step 4 is what makes this validation trustworthy rather than a generic health-check dashboard.
Step 1: Confirm the deploy landed
Determine the deployed ref (from $ARGUMENTS or by asking, mirroring
deploy-audit's ref detection). Refs are treated as untrusted input for
shell purposes: if a ref contains characters outside [A-Za-z0-9._/-], do
not interpolate it directly into a shell command — quote it and confirm with
the user first.
Fetch it and confirm it now points at the commit/tag that was intended to ship — e.g. the deployed branch's SHA matches the base branch's SHA at the time of the deploy, or a release tag was created at the expected commit.
If the deployed ref does not match what was expected, stop and report this first — nothing downstream matters if the wrong thing shipped.
Step 2: Find the deploy pipeline and its start time
Use ToolSearch to find whatever CI/deploy tooling is available in this project (search terms like "circleci", "github actions", "pipeline", "deploy"). Find the pipeline/workflow run that performed this deploy and record:
- Its status (success/failure/in-progress)
- Its start timestamp — this is the anchor for every correlation in later steps
If no CI tooling is discoverable, ask the user for the deploy start time directly rather than guessing.
Step 3: Check rollout health
Use ToolSearch for whatever deployment/orchestration platform the project uses (e.g. terms like "ecs", "kubernetes", "k8s", "cloud run", "deployment"). For each service touched by the deploy, check:
- Running/healthy instance count matches desired count, with none pending
- The running image/version tag matches the new release
Query narrowly — one service at a time — rather than enumerating an entire cluster in one call; a large cluster's full service list can exceed usable output size. If a query risks returning a large amount of data, delegate the enumeration to a subagent/fork and have it return only the summary.
Step 4: Check error tracking, correlated by time
Use ToolSearch for whatever error-tracking tool is available (e.g. terms like "sentry", "error tracking", "exception"). Query for issues first seen in a window starting shortly before the deploy and continuing to now.
For every issue found, compare its first-seen timestamp against the deploy start timestamp from Step 2:
- First seen before deploy start → pre-existing noise, not a regression, regardless of how alarming the error looks. Do not report it as caused by this deploy.
- First seen at or after deploy start → candidate regression. Investigate further (stack trace, affected endpoint/service) and include it in the report.
This timestamp correlation is the single most important step in this skill — do not substitute keyword matching or severity alone for it.
Step 5: Check monitoring and alerting, cross-checked against aggregates
Use ToolSearch for whatever monitoring/alerting tool is available (e.g. terms like "datadog", "monitor", "alert", "metrics"). Find anything in an alerting state for the affected service(s) since the deploy.
Before reporting an alert as a confirmed regression, cross-check it against the underlying aggregate metric (e.g. error rate, latency) for the same service and time window. A monitor tripping does not always mean a real regression — percentile and anomaly-detection monitors can trip on a single outlier. Only report it as a likely regression if the aggregate metric itself shows a corresponding shift after the deploy start time; otherwise note the discrepancy.
Step 6: Re-verify flagged risks
If a prior deploy-audit pass flagged any new feature flags or config risks
for this deploy, re-check those specific items now that the deploy is live
(e.g. confirm a flag is still at its intended default). Skip this step if no
prior audit findings are available.
Step 7: Report
Summarize:
## Deploy Validation Report
**Deployed ref:** <ref> (matches expected: yes/no)
**Deploy pipeline:** <status>, started <timestamp>
### Rollout
<per-service health>
### Error Tracking
- Pre-existing (filtered out): <count>
- Candidate regressions (first seen after deploy): <list with detail>
### Monitoring
- Alerts confirmed against aggregate metrics: <list>
- Alerts noted but not corroborated by aggregates: <list>
### Flags
<re-verified risk items, if any>
### Unverified categories
<any category skipped because no tooling was discoverable>
### Recommendation
<propose remediation only for genuine, deploy-caused findings; explicitly
state when the deploy looks healthy>
Do not propose remediation for anything classified as pre-existing noise.