check-prod
Automates Azure production health checks and system status reporting.
Install
mkdir -p .claude/skills/check-prod && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/18490" && unzip -o skill.zip -d .claude/skills/check-prod && rm skill.zipInstalls to .claude/skills/check-prod
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Check Azure production health: app status, errors, latency, database, dependencies. Use when user says "check prod", "how''s prod", "hows prod doing", "is prod up", "prod status", "health check", "any errors?", "how''s the app doing?", or "check Azure".Key capabilities
- →Check readiness probe status
- →Monitor 5xx errors in 24 hours
- →Evaluate database CPU and memory usage
- →Detect fired Sev1 alerts
- →Analyze error rate trends over 7 days
- →Check resource health for availability
How it works
This skill performs 14 read-only checks on Azure resources using the `az` CLI and `curl` to determine the production health status.
Inputs & outputs
When to use check-prod
- →Check production app health
- →Monitor Azure database CPU usage
- →Identify recent error spikes
About this skill
Check Production
Perform a read-only health assessment of resources in rg-ltc-dev. Discover
resource names at runtime; do not rely on generated suffixes. Require an
authenticated Azure CLI session.
Run independent Azure Monitor and Log Analytics queries concurrently after resource discovery. Cover:
/readystatus and response time- Azure resource health and fired alerts (24h)
- availability failures, request count, 5xx count, and P95 latency (24h)
- exceptions (7d) and error-level traces (24h)
- dependency failures and latency, especially PostgreSQL and
api.github.com - PostgreSQL peak CPU, memory, storage, connections, and minimum CPU credits
- Container App peak CPU/memory and current-revision crash or unhealthy events
- console
Traceback,FATAL,OOMKilled, or segmentation-fault events - verification outcomes and OAuth success/failure activity (24h)
- API worker failures (
verification.worker.failed), overdue attempts (verification.attempt.stuck), and queued versus executing backlog
Use workspace-mode tables AppRequests, AppExceptions, AppTraces,
AppDependencies, AppAvailabilityResults, and AppMetrics. Container App
tables may use either the _CL schema with _s columns or the standard schema.
Verdict
Critical: readiness is non-200; any 5xx; unavailable resource; PostgreSQL dependency failure; OOM/crash; fired Sev1 alert; DB CPU above 80% or credits below 10.
Warning: P95 above 500 ms; failed availability test; recurring exception; other dependency failure; DB CPU 50-80%, memory/storage 70-85%, or credits 10-30; Container App CPU/memory above 80%; unhealthy replicas without matching scale events; OAuth callback failures above 50% of observed OAuth callback outcomes when login activity exists.
Use auth.login.success and auth.callback.* failure events for OAuth outcomes.
Expected request 401s for missing sessions and 303 login redirects are not OAuth
callback failures or unhandled application errors. Request URL attributes should
use route templates, including router prefixes; /unmatched is reserved for
requests without a known route template.
Verification runs in the API under learn-to-cloud-api, not a separate host.
Check worker failures in AppTraces as well as AppExceptions. Both /health
and /ready return 503 when the worker task has finished; ordinary page routes
are not worker health checks. The worker logs only error.type, not raw
exception details. Overdue reasons are
queued_beyond_limit and execution_beyond_limit, with
verification.attempt.age_seconds. Correlate created, execution-started, and
saved completion events by attempt ID; missing completion telemetry alone is not
proof of pending work. Confirm backlog with authorized read-only database access.
Treat worker death as Critical and overdue work as Warning. Do not log prompts,
evidence, fetched source, or credentials while investigating.
Otherwise report Healthy. Missing telemetry is Unknown, not healthy.
Return one overall verdict followed by a compact table containing each signal, its status, observed value, and time window. Put actionable critical findings first and distinguish application failures from Azure telemetry-query failures.
When not to use it
- →When write operations are required
- →When Azure CLI authentication is not configured
- →When a detailed historical analysis beyond 7 days is needed
Prerequisites
Limitations
- →All checks are read-only
- →Requires `az` CLI authentication
- →Thresholds are tuned for specific Azure SKUs
How it compares
This skill provides a standardized, automated health check with a clear verdict, unlike manual checks that can be inconsistent and time-consuming.
Compared to similar skills
check-prod side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| check-prod (this skill) | 0 | 2mo | Review | Intermediate |
| mlops-engineer | 3 | 5mo | No flags | Advanced |
| genkit-infra-expert | 1 | 1mo | Review | Advanced |
| cloudwatch | 1 | 8mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
mlops-engineer
sickn33
Build comprehensive ML pipelines, experiment tracking, and model registries with MLflow, Kubeflow, and modern MLOps tools. Implements automated training, deployment, and monitoring across cloud platforms. Use PROACTIVELY for ML infrastructure, experiment management, or pipeline automation.
genkit-infra-expert
jeremylongshore
Execute use when deploying Genkit applications to production with Terraform. Trigger with phrases like "deploy genkit terraform", "provision genkit infrastructure", "firebase functions terraform", "cloud run deployment", or "genkit production infrastructure". Provisions Firebase Functions, Cloud Run services, GKE clusters, monitoring dashboards, and CI/CD for AI workflows.
cloudwatch
itsmostafa
AWS CloudWatch monitoring for logs, metrics, alarms, and dashboards. Use when setting up monitoring, creating alarms, querying logs with Insights, configuring metric filters, building dashboards, or troubleshooting application issues.
huawei-event-driven-architecture-review
Raishin
Review Huawei Cloud event-driven architecture designs — DMS Kafka dead-letter configuration, ROMA Connect integration flow capacity, FunctionGraph event trigger idempotency, SMN delivery retry policy, consumer group lag monitoring, cross-region event replication, and retry storm prevention.
ecs-runtime-debug-playbook
talolard
Debug AWS ECS or Fargate deployments where CI or workflow status does not match live behavior, especially when an old task definition keeps serving traffic, a new task exits during startup, health checks are false-green, Alembic or schema state may be inconsistent with physical tables, or AWS profil
azure-monitor-ingestion-py
RJsolucoes
|