Groq Observability
Overview
Monitor Groq LPU inference for latency, token throughput, rate limit utilization, and cost. Groq's defining advantage is speed (280-560 tok/s), so latency degradation is the highest-priority signal. The API returns rich timing metadata (queue_time, prompt_time, completion_time) and rate limit headers on every response.
Prerequisites
- A Groq account with an API key exported as the
GROQ_API_KEY environment variable — the groq-sdk client reads it automatically (new Groq()).
- Node.js with
groq-sdk and prom-client installed (npm install groq-sdk prom-client).
- A Prometheus scrape target and (optionally) Grafana for the dashboard panels.
Key Metrics to Track
| Metric |
Type |
Source |
Why |
| TTFT (time to first token) |
Histogram |
Client-side timing |
Groq's main value prop |
| Tokens/second |
Gauge |
usage.completion_time |
Throughput degradation |
| Total latency |
Histogram |
Client-side timing |
End-to-end performance |
| Rate limit remaining |
Gauge |
x-ratelimit-remaining-* headers |
Prevent 429s |
| Token usage |
Counter |
usage.total_tokens |
Cost attribution |
| Error rate by code |
Counter |
Error handler |
Availability |
| Estimated cost |
Counter |
Tokens * model price |
Budget tracking |
Instructions
Apply these six steps in order. Steps 1-2 are the core instrumentation loop —
wrap the client, then feed a Prometheus instrument set from each call. Steps 3-6
add rate-limit tracking, alerting, structured logs, and dashboards on top. The
lean client skeleton is below; the full code for every step lives in
references/implementation.md.
- Instrumented client — wrap
groq.chat.completions.create so latency, tokens, queue time, and estimated cost are captured on the same path as the request (trackedCompletion).
- Prometheus metrics — register a histogram (latency), counters (tokens, cost, errors), and gauges (throughput, rate-limit remaining), then feed them from
emitMetrics.
- Rate limit header tracking — parse
x-ratelimit-remaining-* off every response into a gauge so you alert before a 429, not after.
- Prometheus alert rules — ship latency/rate-limit/throughput/error/cost alerts tuned to Groq's sub-200ms, 280+ tok/s baseline.
- Structured request logging — emit one JSON line per request for log aggregation, preserving per-request detail metrics roll up.
- Dashboard panels — TTFT distribution, tokens/sec, rate-limit utilization, request volume, error rate, cost, and queue time.
import Groq from "groq-sdk";
const groq = new Groq(); // reads GROQ_API_KEY
async function trackedCompletion(model: string, messages: any[]) {
const start = performance.now();
const result = await groq.chat.completions.create({ model, messages });
const latencyMs = performance.now() - start;
const usage = result.usage!;
const metrics = {
model,
latencyMs: Math.round(latencyMs),
tokensPerSec: Math.round(usage.completion_tokens / ((usage as any).completion_time || latencyMs / 1000)),
totalTokens: usage.total_tokens,
};
emitMetrics(metrics); // -> Prometheus (Step 2)
return { result, metrics };
}
See references/implementation.md for the complete
GroqMetrics shape, pricing table, Prometheus instruments, rate-limit tracking,
alert rules, structured logging, and dashboard panel list.
Output
Applying the workflow produces:
- A
trackedCompletion wrapper that returns { result, metrics }, where metrics is a GroqMetrics object (latency, TTFT, tokens/sec, token counts, queue time, estimated cost).
- A Prometheus metric set —
groq_latency_ms (histogram), groq_tokens_total / groq_cost_usd / groq_errors_total (counters), and groq_tokens_per_second / groq_ratelimit_remaining (gauges).
- Five alert rules (
GroqLatencyHigh, GroqRateLimitCritical, GroqThroughputDrop, GroqErrorRateHigh, GroqCostSpike).
- A structured JSON log line per request and a 7-panel dashboard spec.
Examples
Instrument a single completion and emit a structured log line:
const { result, metrics } = await trackedCompletion(
"llama-3.3-70b-versatile",
[{ role: "user", content: "Summarize this incident report in two sentences." }]
);
logGroqRequest(metrics, result.id);
// metrics.tokensPerSec -> 310, metrics.estimatedCostUsd -> 0.000404
For a 429-guard using rate-limit headers and a dashboard health-reading table,
see references/examples.md.
Error Handling
| Issue |
Cause |
Solution |
| 429 with high retry-after |
RPM or TPM exhausted |
Implement request queuing |
| Latency spike > 2s |
Model overloaded or large prompt |
Reduce prompt size or switch to lighter model |
| 503 Service Unavailable |
Groq capacity issue |
Enable fallback to alternative provider |
| Tokens/sec drop |
Streaming disabled or large prompts |
Enable streaming for better perceived performance |
Resources
Source: jeremylongshore/claude-code-plugins-plus-skills → plugins/saas-packs/groq-pack/skills/groq-observability/SKILL.md
1---2name: groq-observability3description: "'Set up observability for Groq integrations: latency histograms, token throughput, rate limit gauges, cost tracking, and Prometheus alerts. Use when instrumenting Groq API calls, building a metrics dashboard, or wiring latency/cost/rate-limit alerts. Trigger with phrases like \"groq monitoring\", \"groq metrics\", \"groq observability\", \"monitor groq\", \"groq alerts\", \"groq dashboard\". '"4allowed-tools: "Read, Write, Edit"5category: devops-and-infra6source_repo: jeremylongshore/claude-code-plugins-plus-skills7source_path: "plugins/saas-packs/groq-pack/skills/groq-observability/SKILL.md"8source_url: https://github.com/jeremylongshore/claude-code-plugins-plus-skills/blob/HEAD/plugins/saas-packs/groq-pack/skills/groq-observability/SKILL.md9---1011# Groq Observability1213## Overview1415Monitor Groq LPU inference for latency, token throughput, rate limit utilization, and cost. Groq's defining advantage is speed (280-560 tok/s), so latency degradation is the highest-priority signal. The API returns rich timing metadata (`queue_time`, `prompt_time`, `completion_time`) and rate limit headers on every response.1617## Prerequisites1819- A Groq account with an API key exported as the `GROQ_API_KEY` environment variable — the `groq-sdk` client reads it automatically (`new Groq()`).20- Node.js with `groq-sdk` and `prom-client` installed (`npm install groq-sdk prom-client`).21- A Prometheus scrape target and (optionally) Grafana for the dashboard panels.2223## Key Metrics to Track2425| Metric | Type | Source | Why |26|--------|------|--------|-----|27| TTFT (time to first token) | Histogram | Client-side timing | Groq's main value prop |28| Tokens/second | Gauge | `usage.completion_time` | Throughput degradation |29| Total latency | Histogram | Client-side timing | End-to-end performance |30| Rate limit remaining | Gauge | `x-ratelimit-remaining-*` headers | Prevent 429s |31| Token usage | Counter | `usage.total_tokens` | Cost attribution |32| Error rate by code | Counter | Error handler | Availability |33| Estimated cost | Counter | Tokens * model price | Budget tracking |3435## Instructions3637Apply these six steps in order. Steps 1-2 are the core instrumentation loop —38wrap the client, then feed a Prometheus instrument set from each call. Steps 3-639add rate-limit tracking, alerting, structured logs, and dashboards on top. The40lean client skeleton is below; the full code for every step lives in41[references/implementation.md](references/implementation.md).42431. **Instrumented client** — wrap `groq.chat.completions.create` so latency, tokens, queue time, and estimated cost are captured on the same path as the request (`trackedCompletion`).442. **Prometheus metrics** — register a histogram (latency), counters (tokens, cost, errors), and gauges (throughput, rate-limit remaining), then feed them from `emitMetrics`.453. **Rate limit header tracking** — parse `x-ratelimit-remaining-*` off every response into a gauge so you alert before a 429, not after.464. **Prometheus alert rules** — ship latency/rate-limit/throughput/error/cost alerts tuned to Groq's sub-200ms, 280+ tok/s baseline.475. **Structured request logging** — emit one JSON line per request for log aggregation, preserving per-request detail metrics roll up.486. **Dashboard panels** — TTFT distribution, tokens/sec, rate-limit utilization, request volume, error rate, cost, and queue time.4950```typescript51import Groq from "groq-sdk";5253const groq = new Groq(); // reads GROQ_API_KEY5455async function trackedCompletion(model: string, messages: any[]) {56 const start = performance.now();57 const result = await groq.chat.completions.create({ model, messages });58 const latencyMs = performance.now() - start;59 const usage = result.usage!;60 const metrics = {61 model,62 latencyMs: Math.round(latencyMs),63 tokensPerSec: Math.round(usage.completion_tokens / ((usage as any).completion_time || latencyMs / 1000)),64 totalTokens: usage.total_tokens,65 };66 emitMetrics(metrics); // -> Prometheus (Step 2)67 return { result, metrics };68}69```7071See [references/implementation.md](references/implementation.md) for the complete72`GroqMetrics` shape, pricing table, Prometheus instruments, rate-limit tracking,73alert rules, structured logging, and dashboard panel list.7475## Output7677Applying the workflow produces:7879- A **`trackedCompletion` wrapper** that returns `{ result, metrics }`, where `metrics` is a `GroqMetrics` object (latency, TTFT, tokens/sec, token counts, queue time, estimated cost).80- A **Prometheus metric set** — `groq_latency_ms` (histogram), `groq_tokens_total` / `groq_cost_usd` / `groq_errors_total` (counters), and `groq_tokens_per_second` / `groq_ratelimit_remaining` (gauges).81- **Five alert rules** (`GroqLatencyHigh`, `GroqRateLimitCritical`, `GroqThroughputDrop`, `GroqErrorRateHigh`, `GroqCostSpike`).82- A **structured JSON log line** per request and a **7-panel dashboard** spec.8384## Examples8586Instrument a single completion and emit a structured log line:8788```typescript89const { result, metrics } = await trackedCompletion(90 "llama-3.3-70b-versatile",91 [{ role: "user", content: "Summarize this incident report in two sentences." }]92);93logGroqRequest(metrics, result.id);94// metrics.tokensPerSec -> 310, metrics.estimatedCostUsd -> 0.00040495```9697For a 429-guard using rate-limit headers and a dashboard health-reading table,98see [references/examples.md](references/examples.md).99100## Error Handling101102| Issue | Cause | Solution |103|-------|-------|----------|104| 429 with high retry-after | RPM or TPM exhausted | Implement request queuing |105| Latency spike > 2s | Model overloaded or large prompt | Reduce prompt size or switch to lighter model |106| 503 Service Unavailable | Groq capacity issue | Enable fallback to alternative provider |107| Tokens/sec drop | Streaming disabled or large prompts | Enable streaming for better perceived performance |108109## Resources110111- [references/implementation.md](references/implementation.md) — full code for all six observability steps.112- [references/examples.md](references/examples.md) — worked instrumentation, 429-guard, and dashboard-reading examples.113- [Groq API Reference (usage fields)](https://console.groq.com/docs/api-reference)114- [Groq Rate Limits](https://console.groq.com/docs/rate-limits)115- [prom-client on npm](https://www.npmjs.com/package/prom-client)116- For incident response procedures, see the `groq-incident-runbook` skill.117118---119120**Source:** [`jeremylongshore/claude-code-plugins-plus-skills`](https://github.com/jeremylongshore/claude-code-plugins-plus-skills) → `plugins/saas-packs/groq-pack/skills/groq-observability/SKILL.md`