cloud-weaver-monitor

Monitor

Confirm the deployed recipe is healthy. Called optionally after cloud-weaver-repo-setup completes — when the GHA pipeline succeeds but the user wants an explicit health confirmation, or when diagnosing a problem.

In the v2 flow the pipeline itself waits for kamal deploy to finish, so in the happy path this skill is a belt-and-suspenders check, not a required step.

1. Determine the health URL and SSH key

Required inputs (passed from start-cloud or cloud-weaver-repo-setup):

Each recipe exposes a health endpoint:

SSH key path (per-repo, generated by cloud-weaver-repo-setup):

SSH_KEY="$HOME/.ssh/cw-${REPO_NAME}"

2. Poll the health endpoint

Run the poller (pure stdlib, no dependencies). It waits a grace period for containers to boot, then probes with exponential backoff until HTTP 200 or the timeout budget runs out:

python3 <this-skill-dir>/scripts/health-check.py \
  --url "https://${PUBLIC_IP}.nip.io/health" \
  --timeout 600 --initial-delay 30

Give the user plain-language status updates while it runs (Estou aguardando a aplicação subir…). On success the script exits 0. Use --output report.json when the caller wants the attempt history.

3. On success — proceed

Report to the user that the app is healthy. Hand off to the final report.

4. On failure — diagnose via SSH

If the health check times out or never returns 200, collect VM diagnostics:

bash <this-skill-dir>/scripts/diagnose.sh \
  --ssh-key "$HOME/.ssh/cw-${REPO_NAME}" --ip "$PUBLIC_IP"

This gathers: docker ps, /data disk usage, memory, the Docker daemon log and uptime. Read the output and reason out loud:

• Containers not running → check Kamal service logs on the VM:

  ssh -i "$HOME/.ssh/cw-${REPO_NAME}" root@"$PUBLIC_IP" \
    "docker ps -a && docker logs \$(docker ps -lq) --tail 50"

• Container restarting → view its logs for the exit reason.
• Disk/memory pressure → the plan may be too small; suggest a larger VM plan.
• Docker daemon down → systemctl status docker on the VM.

Use the per-repo SSH key (~/.ssh/cw-<repo-name>, user root, -o StrictHostKeyChecking=accept-new) for any follow-up commands. Report findings to the user in plain PT-BR and recommend the next action.

Rollback

Automated rollback is not implemented. If diagnostics show the VM itself cannot be recovered, tell the user clearly — then offer to run cloud-weaver-teardown and start fresh.

Bundled Resources

• `scripts/health-check.py` — HTTP poller (stdlib, backoff, report JSON)
• `scripts/diagnose.sh` — SSH diagnostics collector (--dry-run supported)