Groq uptime history: what the status page shows

Groq uptime history, as recorded on its public status page, tells a story of a fast-growing inference provider with mostly green days and occasional brownouts. The raw incident log is more instructive than the aggregate uptime percentage, because Groq’s LPU-based stack fails in specific ways that a simple operational/degraded toggle hides.

What the Groq status page actually exposes

Groq runs its status page on Statuspage (status.groq.com). The interface shows a current status banner, component-level health (API, Dashboard, Playground), and a 90-day uptime bar. Behind that UI is a JSON API that exposes the same data without the marketing gloss.

curl -s https://status.groq.com/api/v2/summary.json | jq '.status.indicator, .components[].name'

The summary endpoint returns none, minor, major, or critical for the overall indicator. Component objects carry their own status field: operational, degraded_performance, partial_outage, or major_outage. A typical response marks the API component as operational even when the incident feed shows active monitoring of latency spikes.

Incident taxonomy

Groq’s incident archive splits into three buckets you should care about:

• Degraded performance – API responds, but p50/p99 latency climbs or token throughput drops. The status page often marks this yellow while successful requests still return 200.
• Partial outage – Specific models or regions fail. For Groq, this usually means a newly launched model sits in partial_outage while older ones stay operational.
• Major outage – Full API rejection, typically 503s across the board.

The Groq uptime history shows far more yellow than red. That is the central pattern: the system rarely dies completely, but it regularly slows down under load.

Pulling the raw log

You can reconstruct your own availability timeline from the incidents endpoint:

curl -s https://status.groq.com/api/v2/incidents.json | jq '.incidents[] | {name, status, created_at, resolved_at}'

Each incident carries created_at and resolved_at (or null if ongoing). Scripting over this array lets you compute how many hours per month were spent in degraded_performance versus operational. The status page’s 90-day bar will not do that math for you.

Reading Groq uptime history beyond the green dot

A 90-day uptime bar that reads 99.9% can coexist with a terrible week of latency. The status page does not measure tail latency, and Groq’s value proposition is tail latency. If your application needs consistent sub-100ms time-to-first-token, a day marked “operational” with p99 of 800ms is a silent failure.

Degraded performance != downtime

Filter the incident list for active or recent monitoring:

curl -s https://status.groq.com/api/v2/incidents.json | jq '.incidents[] | select(.status=="monitoring") | {name, created_at, impact}'

You will see entries titled “Elevated latency on llama-3.1-70b” or “Increased error rates for chat completions”. The impact field often says minor, but for a latency-sensitive caller, minor on the status page is major in your dashboards.

The gap between API success and usable latency

Groq’s LPUs deliver extraordinary speed at steady state. When a cluster saturates, the queue depth grows and the API starts shedding load by slowing responses rather than dropping connections. Your client sees a slow stream, not a timeout. If you only alert on non-200 status codes, you will miss these events entirely. Groq uptime history therefore understates the number of moments where the service was technically available but unusable for real-time UX.

Why Groq’s architecture produces these incidents

Groq builds custom Language Processing Units (LPUs) optimized for sequential token generation. This is not GPU time-slicing; it is fixed-function silicon with deterministic throughput per chip. That design yields the headline speeds, but it creates rigid capacity boundaries.

Single-purpose clusters and scaling friction

Adding capacity means physically deploying more LPU cards and weaving them into the serving topology. When a viral demo or a new model release drives a 10x traffic spike, Groq cannot elastic-scale onto spare cloud GPUs. The status page goes yellow until the traffic recedes or new hardware comes online. This is a structural constraint, not a bug. Any Groq uptime history will show incident clustering during traffic surges that competitors with GPU autoscaling absorb more quietly.

Model onboarding spikes

Every Groq uptime history archive shows incident clusters around new model additions. A fresh model (e.g., a new open-weight release) draws migration traffic from existing routes. The serving layer must load weights, warm caches, and rebalance. During that window, degraded_performance is common even if the overall indicator stays green. The incident titles usually name the specific model, which is useful signal: if you depend on that model, expect a rough first 24 hours after launch.

Building resilience around Groq’s track record

If you depend on Groq for production, treat its status page as a lagging indicator. Build your own synthetic probes that assert latency, not just reachability.

Synthetic checks that match real traffic

A minimal Python probe using the OpenAI-compatible Groq endpoint:

import time, openai

client = openai.OpenAI(base_url="https://api.groq.com/openai/v1", api_key="groq-key")

start = time.monotonic()
try:
    r = client.chat.completions.create(
        model="llama-3.1-70b-versatile",
        messages=[{"role": "user", "content": "ping"}],
        max_tokens=5,
    )
    ttft = time.monotonic() - start
    assert ttft < 0.5, f"TTFT {ttft}s exceeds SLO"
except Exception as e:
    alert(f"Groq probe failed: {e}")

Run this from multiple regions. When the probe fails your SLO, flip traffic even if status.groq.com still shows operational.

Fallback patterns in code

The naive fallback is a try/except to a second provider:

from openai import OpenAI

groq = OpenAI(base_url="https://api.groq.com/openai/v1", api_key="groq-key")
backup = OpenAI(base_url="https://api.openai.com/v1", api_key="oa-key")

def complete(messages):
    try:
        return groq.chat.completions.create(model="llama-3.1-70b", messages=messages)
    except Exception:
        return backup.chat.completions.create(model="gpt-4o-mini", messages=messages)

This works for hard outages but not for slow degradations. You need a timeout and a latency budget:

import asyncio, openai

async def complete_with_budget(messages, budget=0.4):
    try:
        return await groq.chat.completions.create(
            model="llama-3.1-70b", messages=messages, timeout=budget
        )
    except Exception:
        return await backup.chat.completions.create(model="gpt-4o-mini", messages=messages)

An inference gateway such as n4n.ai removes this boilerplate by exposing one OpenAI-compatible endpoint across 240+ models and automatic fallback when a provider is rate-limited or degraded, while still honoring client routing directives and forwarding provider cache-control hints. That matters when you want to keep Groq as a preferred route but never block on its yellow days.

Tradeoffs: speed vs continuity

Groq is the fastest commodity LLM inference available for many open-weight models. That speed is real and measurable. The tradeoff is operational: you accept periodic degraded windows where the speed advantage vanishes and you are left with a slower-than-GPU experience because the queue is backing up.

When to bet on Groq alone

• Internal tools where a 2-second response is fine and cost is zero.
• Batch jobs that can retry with backoff and tolerate variable throughput.
• Prototypes demonstrating LPU speed to stakeholders.

In these cases, the Groq uptime history is reassuring: complete outages are rare, and you can absorb yellow days.

When to abstract it behind a gateway

• User-facing latency SLOs under 500ms at p99.
• Revenue-critical paths where a yellow status page cannot page your on-call.
• Multi-model routing that needs to shift load without code deploys.

If you operate in this category, the status page is necessary but insufficient. You need the latency probes and fallback logic from the previous section, or a gateway that encodes them.

Takeaway

Read the Groq uptime history as a record of degraded-performance events, not just outages. The status page shows a provider that rarely falls completely over but regularly hits capacity ceilings inherent to its custom hardware. Build latency-aware probes, implement budgeted fallbacks, and treat Groq as a high-speed lane that sometimes closes for repaving. Engineers who ship against Groq’s real behavior—not its green dot—will keep their p99s honest.