How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/fagnerlopes/cloud-weaver --skill cloud-weaver-monitorBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
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):
| Variable | Example |
|---|---|
PUBLIC_IP | 200.1.2.3 |
REPO_NAME | meu-hermes |
Each recipe exposes a health endpoint:
| Recipe | Health check URL |
|---|---|
hermes-agent | https://${PUBLIC_IP}.nip.io/health |
waha | https://${PUBLIC_IP}.nip.io/api/health |
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 30Give 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 dockeron 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-runsupported)
