القائمة
>-
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
استنادا إلى تصنيف SOC المهني
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/CleanExpo/NodeJS-Starter-V1 --skill health-checkيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
Route complex requests to the right specialist agent or chain of agents. This skill acts as the central brain of an agent swarm — it analyses what the user needs, determines which specialist domain(s) are required, and coordinates parallel or sequential agent execution. Use this skill when a request spans multiple domains (e.g., "research competitors and create a pitch deck"), when you need to decide which specialist should handle an ambiguous request, or when a task requires a multi-step pipeline across different skills. Triggers on: multi-step requests, cross-domain tasks, "coordinate", "plan this out", "I need help with multiple things", or any complex request that touches more than one specialist area. Also triggers when the user seems unsure which tool or approach to use.
>-
Hybrid DAG execution primitive combining deterministic and agentic nodes with hard iteration caps
| id | health-check |
| name | health-check |
| type | skill |
| version | 1.0.0 |
| created | 20/03/2026 |
| modified | 20/03/2026 |
| status | active |
| metadata | {"author":"NodeJS-Starter-V1","version":"1.0.0","locale":"en-AU"} |
| description | >- |
| context | fork |
Codifies the project's three-tier health probe architecture (shallow liveness, readiness, deep dependency checks), Docker container healthchecks, cron-based periodic monitoring, route discovery verification, and the comprehensive system health script. Patterns align with Kubernetes probe conventions even when running outside K8s.
Codifies liveness, readiness, and deep dependency health endpoints for NodeJS-Starter-V1's Next.js and FastAPI services, covering three-tier probe architecture, Docker healthchecks, cron-based monitoring, route discovery verification, and the system health script.
metrics-collector instead)structured-logging instead)dashboard-patterns instead)graceful-shutdown when available)Promise.all or asyncio.gather. Never check sequentially — a slow database should not delay the Redis check.| Endpoint | Type | Location |
|---|---|---|
GET /health | Liveness |
apps/backend/src/api/routes/health.pyGET /ready | Readiness | apps/backend/src/api/routes/health.py |
GET /api/agents/{id}/health | Agent health | apps/backend/src/api/routes/agent_dashboard.py |
| Endpoint | Type | Location |
|---|---|---|
GET /api/health | Shallow liveness | apps/web/app/api/health/route.ts |
GET /api/health/deep | Deep dependency | apps/web/app/api/health/deep/route.ts |
GET /api/health/routes | Route discovery | apps/web/app/api/health/routes/route.ts |
GET /api/cron/health-check | Periodic cron | apps/web/app/api/cron/health-check/route.ts |
| Service | Command | Interval | Timeout | Retries |
|---|---|---|---|---|
| PostgreSQL | pg_isready -U starter_user -d starter_db | 10s | 5s | 5 |
| Redis | redis-cli ping | 10s | 5s | 5 |
scripts/health-check.ps1 — 6-phase comprehensive health check (prerequisites, database, backend, frontend, integration, summary) with exit code 0 (healthy) or 1 (unhealthy).
All health endpoints use a three-state status:
| Status | HTTP Code | Meaning | Action |
|---|---|---|---|
healthy | 200 | All systems operational | None |
degraded | 200 | Functional but impaired | Monitor, alert |
unhealthy | 503 | Cannot serve requests | Remove from load balancer |
if any dependency is unhealthy → overall = unhealthy (503)
else if any dependency is degraded → overall = degraded (200)
else → overall = healthy (200)
Returns immediately with minimal computation. Used by load balancers and orchestrators to confirm the process is alive.
Backend (/health):
@router.get("/health")
async def health_check() -> dict[str, str]:
return {
"status": "healthy",
"timestamp": datetime.now().isoformat(),
"version": "0.1.0",
}
Frontend (/api/health):
interface HealthResponse {
status: "healthy" | "degraded" | "unhealthy";
timestamp: string;
version: string;
uptime: number;
environment: string;
}
Rules: No database calls, no external service checks, no computation. Must respond in < 50ms.
Confirms the service can accept and process requests. Checks that critical dependencies are reachable.
Backend (/ready):
@router.get("/ready")
async def readiness_check() -> dict[str, str]:
# Check database connectivity
# Check Redis connectivity
# Check AI provider availability
return {"status": "ready", "timestamp": datetime.now().isoformat()}
Rules: Check only fast, critical dependencies (database, cache). Timeout each check at 2–5 seconds. Do not check optional or slow services.
Checks all dependencies in parallel with latency measurement. Used for debugging and monitoring dashboards, not for load balancer probes (too slow).
Frontend (/api/health/deep):
interface DependencyCheck {
name: string;
status: "healthy" | "degraded" | "unhealthy" | "unchecked";
latency_ms: number | null;
error: string | null;
last_checked: string;
}
Each dependency checker follows this pattern:
AbortSignal.timeout(5000))Date.now() - start)healthy (success), degraded (slow or partial), unhealthy (error/timeout)Checks run in parallel via Promise.all:
const [database, backend, verification] = await Promise.all([
checkDatabase(),
checkBackend(),
checkVerificationSystem(),
]);
The summary aggregates results:
const summary = {
total_checks: checks.length,
passed: checks.filter(c => c.status === "healthy").length,
failed: checks.filter(c => c.status === "unhealthy").length,
degraded: checks.filter(c => c.status === "degraded").length,
};
Docker Compose healthchecks use CMD-SHELL with service-native commands:
services:
postgres:
healthcheck:
test: ["CMD-SHELL", "pg_isready -U starter_user -d starter_db"]
interval: 10s
timeout: 5s
retries: 5
redis:
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 10s
timeout: 5s
retries: 5
For application containers, use curl or wget against the liveness endpoint:
backend:
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
start_period gives the application time to initialise before healthchecks begin. Use depends_on with condition: service_healthy to sequence container startup.
The project's /api/cron/health-check runs every 5 minutes, pings the backend, and logs results. Secured with CRON_SECRET bearer token.
Pattern for adding new periodic checks:
export async function GET(request: Request) {
// 1. Verify CRON_SECRET
const authHeader = request.headers.get("authorization");
if (authHeader !== `Bearer ${process.env.CRON_SECRET}`) {
return new NextResponse("Unauthorized", { status: 401 });
}
// 2. Run checks with latency measurement
const start = Date.now();
const response = await fetch(`${backendUrl}/health`, {
signal: AbortSignal.timeout(5000),
});
const latency = Date.now() - start;
// 3. Log results
logger.info("Health check cron", { backend: response.ok, latency });
// 4. Alert if unhealthy
if (!response.ok) { logger.error("Backend unhealthy"); }
// 5. Return results
return NextResponse.json({ status: response.ok ? "healthy" : "unhealthy" });
}
The /api/health/routes endpoint discovers all API routes by scanning the filesystem and optionally verifies each GET endpoint:
app/api/ for route.ts files?verify=true): Send GET request to each endpoint with 5-second timeoutverified (200 OK), error (non-200 or timeout), unverified (not tested)When integrating a new service, add a checker following this template:
async function checkNewService(): Promise<DependencyCheck> {
const start = Date.now();
const result: DependencyCheck = {
name: "service_name",
status: "unchecked",
latency_ms: null,
error: null,
last_checked: new Date().toISOString(),
};
try {
// Service-specific check (e.g., ping, SELECT 1, PING)
const response = await fetch(serviceUrl, {
signal: AbortSignal.timeout(5000),
});
result.latency_ms = Date.now() - start;
result.status = response.ok ? "healthy" : "degraded";
if (!response.ok) result.error = `HTTP ${response.status}`;
} catch (e) {
result.latency_ms = Date.now() - start;
result.status = "unhealthy";
result.error = e instanceof Error ? e.message : "Unknown error";
}
return result;
}
Then add it to the Promise.all array in the deep health endpoint.
| Anti-Pattern | Why It Fails | Correct Approach |
|---|---|---|
| Database query in liveness probe | Probe fails when DB is slow, kills healthy process | Liveness = process alive only; DB check in readiness |
| Sequential dependency checks | Total latency = sum of all checks | Promise.all / asyncio.gather for parallel |
| 200 OK when unhealthy | Load balancer keeps routing traffic to broken instance | 503 for unhealthy, 200 for healthy/degraded |
| No timeout on dependency checks | Single hung dependency blocks entire health response | AbortSignal.timeout(5000) on every check |
| Exposing sensitive details in health response | Internal errors, stack traces leaked to public | Return status + latency only; log details server-side |
No start_period in Docker healthcheck | Container marked unhealthy during boot | Set start_period to cover startup time |
| Hardcoded service URLs in health checks | Breaks across environments | Use environment variables (BACKEND_URL, etc.) |
healthy / degraded / unhealthy status valuestimestamp and versionPromise.all or asyncio.gatherinterval, timeout, retries configuredstart_period covers application boot timecondition: service_healthy for dependent servicesmetrics-collectorstructured-logging[AGENT_ACTIVATED]: Health Check
[PHASE]: {Design | Implementation | Review}
[STATUS]: {in_progress | complete}
{health check analysis or implementation guidance}
[NEXT_ACTION]: {what to do next}
health_check_duration_ms histogram per dependencyhealth_check_status gauge (1=healthy, 0.5=degraded, 0=unhealthy)SYS_HEALTH_DEPENDENCY_UNAVAILABLE (503) — critical dependency unreachableSYS_HEALTH_TIMEOUT (504) — dependency check exceeded timeout/api/cron/health-check runs every 5 minutes with CRON_SECRET authStatusPulse component for live dependency status indicatorsDataStrip for health check latency metrics