Agent skill · data analytics · jeremylongshore

coreweave-observability

Set up GPU monitoring and observability for CoreWeave workloads.

Why this skill is useful

Provides specific metrics and alerting rules for monitoring GPU workloads on CoreWeave that the AI wouldn't reliably generate on its own.

What it needs

Requires grep, kubectl installed locally. About 3k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.

What this skill does

CoreWeave Observability Community-contributed. Not affiliated with, endorsed by, or sponsored by CoreWeave, Inc. CoreWeave is a registered trademark of CoreWeave, Inc. Overview CoreWeave runs GPU-intensive workloads on Kubernetes where hardware failures, memory exhaustion, and underutilization directly impact cost and reliability. Observability must cover DCGM GPU metrics, Kubernetes pod health, inference latency, and job completion rates. Proactive monitoring prevents wasted spend on idle GPUs and catches OOM conditions before they cascade. Prerequisites A metrics backend receiving Kubernetes and DCGM exporter metrics. A named dashboard and on-call owner for the namespace or service. Log and trace redaction rules that exclude prompts, model outputs, tokens, and credentials. Instructions 1. Tag metrics with bounded values such as namespace, model family, and status; do not use request IDs, prompts, or user identifiers as labels. 2. Build dashboards for utilization, memory, queue depth, latency, error rate, and restart rate, then set alert thresholds from a measured baseline. 3. Route critical alerts to the responsible on-call team and link a runbook that includes a safe scale-down or rollback action. 4. Test one alert in a non-production namespace and verify that the receipt contains only operational metadata, not workload data. …

How to use it

Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:

@skills jeremylongshore/coreweave-observability

View the source on GitHub

Browse the @skills marketplace