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.zip

Installs 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".
253 chars✓ has a “when” triggerlonger than Claude Code's old 250-char listing cap (fine on current versions)
Intermediate

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

You give it
Azure subscription ID and resource group name
You get back
A verdict of Critical, Warning, or Healthy based on 14 checks

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:

  • /ready status 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

az CLI authenticated with an Azure account

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.

SkillInstallsUpdatedSafetyDifficulty
check-prod (this skill)02moReviewIntermediate
mlops-engineer35moNo flagsAdvanced
genkit-infra-expert11moReviewAdvanced
cloudwatch18moReviewIntermediate

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.

333

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.

15

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.

12

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.

00

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

00

azure-monitor-ingestion-py

RJsolucoes

|

00

Search skills

Search the agent skills registry