monitor-services

Health-checks and auto-restarts Pollinations GPU inference services across Vast.ai, RunPod, Lambda, and OVH.

5.0k|1.0k|Updated Apr 15, 2021
One-click install
npx skills add https://github.com/pollinations/pollinations --skill monitor-services
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: monitor-services
Source: https://github.com/pollinations/pollinations/tree/main/.claude/skills/monitor-services
Command: npx skills add https://github.com/pollinations/pollinations --skill monitor-services

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Pollinations runs image, video, and music generation on a fleet of distributed GPU backends (Flux on Vast.ai, Z-Image and Klein on RunPod, LTX-2 and ACE-Step on a Lambda GH200, legacy image on OVH). When a pod dies, a GPU falls off the bus, or a tunnel degrades, production requests fail with 524 timeouts. This Skill automates detection and recovery of those failures.

Core Features & Use Cases

  • Fleet-wide health checks: Probes the gen.pollinations.ai worker registry plus per-service health endpoints for Flux, Z-Image, LTX-2, ACE-Step, Klein, DreamShaper, and the legacy OVH image service.
  • Auto-restart and recovery: Restarts systemd units, relaunches pod processes, and walks through full RunPod pod recreation including provisioning, model downloads, and secret pushes.
  • Failure diagnosis: Cross-checks RunPod pod status against the live registry to catch pods that are running and billing but serving zero traffic, and distinguishes tunnel degradation from GPU failure.
  • Use Case: Run it on a recurring loop (e.g. every 30 minutes) so an on-call operator gets a status table of every GPU backend with automatic restart attempts for anything unhealthy.

Quick Start

Ask the AI to run the monitor-services check on all Pollinations GPU backends and report a status table with latency for each service.

Frequently Asked Questions about monitor-services

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I health-check GPU inference servers across multiple cloud providers?

Query the central worker registry first, then curl each backend's /health endpoint directly. This Skill checks the gen.pollinations.ai registry plus per-service endpoints on Vast.ai, RunPod, Lambda, and OVH hosts, reporting status and latency per service.

How do I restart a crashed RunPod pod serving an image model?

SSH into the pod and run its relaunch script for a dead process, or stop and start the pod with runpodctl if the GPU fell off the bus. Stop/start wipes the container disk, so back up the provision script first and re-provision afterward.

Why does a RunPod pod show RUNNING but serve no traffic?

The pod's server process may have died or its GPU may have fallen off the bus while the control plane still reports RUNNING. Cross-check the pod list against the live worker registry; any RUNNING pod absent from the registry is idle and needs a relaunch or restart.

Can health checks pass while the service is still broken?

Yes. A worker can heartbeat to the registry while its tunnel is too slow to serve requests, and a heartbeat thread keeps firing even when generation hangs. Always time a real probe of the registered URL and verify old processes actually died after a relaunch.

What credentials are needed to run these service checks?

SSH keys are stored in SOPS-encrypted secrets (extracted with sops and jq), the OVH host uses a local key, and end-to-end tests use a test API token from the .testingtokens file. RunPod access uses the account API key from the runpodctl config.