---
name: post-deploy-canary-watch
description: "Sets out what to watch in the first hour after a deploy, with numeric thresholds that tell you when to roll back. Use when a release is about to go live and the on-call engineer needs a timed watch plan with numeric rollback thresholds for the first hour. Do not use for investigating an outage already in progress or building a monitoring stack. Related topics: devops, technical."
---

# Post-Deploy Canary Watch

Sets out what to watch in the first hour after a deploy, with numeric thresholds that tell you when to roll back.

## When to use

Use this skill when a release is about to go live and the on-call engineer needs a timed watch plan with numeric rollback thresholds for the first hour. Do not use it for investigating an outage already in progress or building a monitoring stack.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Record the baseline for error rate, latency, and traffic that thresholds will be measured against.
3. Divide the first hour into four time blocks and assign the signals to check in each.
4. Give every signal a warning level and a rollback level as a number against the baseline.
5. Add signals specific to the risky parts of this change.
6. State who decides on rollback, how to execute it, and the all-clear condition that ends the watch.

## Inputs

- **What is being deployed** (longer free text)
- **Normal baseline** (longer free text)
- **Monitoring tools** (free text, e.g. "Datadog and Sentry")
- **Rollout style** (choose one: Full release, Canary percentage, Blue green, Feature flag)
- **Critical user flows** (longer free text)
- **Who is on call** (free text, e.g. "Role only")

## Output

A table of time blocks and signals with warning and rollback thresholds, the change-specific signals, the rollback owner and method, and the all-clear condition.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Post-Deploy Canary Watch

Plan the first hour after this deploy.

- What is being deployed: {{What is being deployed}}
- Normal baseline: {{Normal baseline}}
- Monitoring tools: {{Monitoring tools}}
- Rollout style: {{Rollout style}}
- Critical user flows: {{Critical user flows}}
- Who is on call: {{Who is on call}}

Build a watch plan in time blocks: minutes 0 to 5, 5 to 15, 15 to 30, and 30 to 60. For each block list the signals to check: error rate, latency percentiles, saturation of CPU and memory and connections, queue depth, and the success rate of each critical flow, plus new error types in logs. Give every signal a number: a warning level and a rollback level expressed against the baseline, such as error rate double the baseline for five minutes means roll back. Add signals specific to this change, tied to its risky parts. State who decides on a rollback, how it is done, and what to record. Finish with an all-clear condition that ends the watch.

## Pitfalls

- Thresholds without numbers, which turn rollback into a debate under pressure.
- Watching averages when a latency percentile shows the problem.
- Ending the watch on a timer instead of a condition.