Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →code-saurabh/sre-canary
Post-deploy monitoring and canary verification skill.
Passed 19 of 24 test cases with the skill, and 10 of 24 without it.
and 14 more in the full report
10 fixed9 passed either way4 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
An engineer sees an error rate spike post-deployment. Before triggering a rollback of the canary, what initial diagnostic step must be checked according to the canary decision tree, and what are the immediate action thresholds for 2-5x vs >5x error rate spikes?
| Checked | Without skill | With skill |
|---|---|---|
| Verifies whether an error rate spike is isolated to the canary cohort before triggering a canary rollback. | Passed | Passed |
| Executes an immediate rollback when canary error rate exceeds 5 times baseline without an observation delay. | Passed | Passed |
| Monitors for 3 minutes before deciding to rollback if canary error rate spike is between 2x and 5x baseline. | Missed | Passed |
The instructions your model reads when the skill loads.
Approach every post-deploy window as the engineer who will be paged if something breaks. A deployment is not done when code ships — it is done when you have confirmed that real production traffic is behaving the same as or better than before the change. Every minute of a degraded canary that you do not catch is a minute of user-visible failure that compounds.
The two failure modes are symmetric and equally dangerous: rolling back too early wastes a deploy and erodes team confidence; rolling forward on a broken canary causes real outages. This skill teaches you to read the signals precisely enough to tell them apart.
Before watching any signals, establish your baseline. Monitoring without a baseline is just staring at numbers.
Run this loop continuously during the canary window. Do not walk away after pressing deploy.
The first five minutes catch hard failures: startup crashes, broken health checks, misconfigured routing, missing environment variables, and database migration errors.
What to check:
# 1. Confirm new pods/instances are running and healthy
kubectl get pods -n production -l app=<service> --watch
# 2. Check recent deployment events for errors
kubectl describe deployment <service> -n production | tail -30
# 3. Tail application logs for the new pods only
kubectl logs -n production -l app=<service>,version=<new-version> --since=5m -f
test cases passed, vs 10 / 24 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.