Use when performing service mesh health check — performs a comprehensive health check of a service mesh deployment, evaluating control plane status, data plane proxy health, mTLS coverage, traffic policies, and observability configuration. Use this template for periodic mesh audits or before major mesh upgrades.
Scanned 9/8/2026
Install to Claude Code
npx -y skills add cloudthinker-ai/CloudSkills --skill service-mesh-health-check --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Service Mesh Health Check?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/cloudthinker-ai-service-mesh-health-check)More formats (shields.io, HTML) on the badges page.
---
name: service-mesh-health-check
enabled: true
description: |
Use when performing service mesh health check — performs a comprehensive
health check of a service mesh deployment, evaluating control plane status,
data plane proxy health, mTLS coverage, traffic policies, and observability
configuration. Use this template for periodic mesh audits or before major mesh
upgrades.
required_connections:
- prefix: kubernetes
label: "Kubernetes Cluster"
- prefix: mesh
label: "Service Mesh Control Plane"
config_fields:
- key: mesh_type
label: "Service Mesh Type"
required: true
placeholder: "e.g., Istio, Linkerd, Consul Connect"
- key: cluster_name
label: "Cluster Name"
required: true
placeholder: "e.g., prod-us-east-1"
features:
- SERVICE_MESH
- NETWORKING
- SRE_OPS
---
# Service Mesh Health Check
## Phase 1: Control Plane Health
Verify the control plane is functioning correctly.
- [ ] Control plane pods running and healthy
- [ ] Control plane version: ___
- [ ] Certificate authority status and certificate expiry dates
- [ ] Configuration validation (no rejected or conflicting configs)
- [ ] Control plane resource utilization (CPU, memory)
- [ ] Control plane high availability: replicas running vs desired
- [ ] API server connectivity from control plane
## Phase 2: Data Plane Health
Assess sidecar proxy status across workloads.
| Namespace | Total Pods | Injected (%) | Proxy Version | Proxy Health | Config Sync Status |
|-----------|-----------|--------------|---------------|--------------|-------------------|
| | | | | | |
- [ ] Identify pods without sidecar injection
- [ ] Identify pods with outdated proxy versions
- [ ] Check proxy resource utilization (CPU, memory per proxy)
- [ ] Verify proxy-to-control-plane connectivity
## Phase 3: Security Assessment
- [ ] mTLS mode: STRICT / PERMISSIVE / DISABLED
- [ ] Percentage of traffic encrypted with mTLS: ___%
- [ ] Authorization policies in place: Y/N
- [ ] Peer authentication policies configured: Y/N
- [ ] Certificate rotation functioning: Y/N
- [ ] External traffic ingress security: reviewed
**mTLS Coverage Matrix:**
| Source Namespace | Destination Namespace | mTLS Status | Policy |
|-----------------|----------------------|-------------|--------|
| | | | |
## Phase 4: Traffic Management Review
- [ ] Virtual services configured and valid
- [ ] Destination rules configured and valid
- [ ] Traffic shifting / canary configurations reviewed
- [ ] Circuit breakers configured for critical services
- [ ] Retry and timeout policies appropriate
- [ ] Rate limiting policies in place where needed
## Phase 5: Observability Verification
- [ ] Distributed tracing functional (sample traces verified)
- [ ] Metrics collection active (request rate, error rate, latency)
- [ ] Access logging configured appropriately
- [ ] Dashboards present and showing data
- [ ] Alerts configured for mesh-level failures
## Counter-Rationalizations
| Shortcut | Counter | Why |
|----------|---------|-----|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
## Output Format
### Summary
- **Mesh type/version:** ___
- **Cluster:** ___
- **Overall health:** Healthy / Degraded / Unhealthy
- **mTLS coverage:** ___%
- **Sidecar injection rate:** ___%
- **Critical findings:** ___
### Action Items
- [ ] Remediate any control plane issues immediately
- [ ] Upgrade outdated sidecar proxies
- [ ] Enable mTLS STRICT mode for namespaces still in PERMISSIVE
- [ ] Add missing authorization policies
- [ ] Fix observability gaps
- [ ] Schedule mesh upgrade if version is behind
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!