Groq API SLA and Uptime: What Is Actually Committed
"What uptime does Groq guarantee?" has a shorter answer than most teams expect — and the follow-up question, what you can promise your own customers on top of it, is the one that actually matters.
📡 Monitor your APIs — know when they go down before your users do
Better Stack checks uptime every 30 seconds with instant Slack, email & SMS alerts. Free tier available.
Affiliate link — we may earn a commission at no extra cost to you
Groq sells speed, and speed is the reason teams put it on the critical path. That makes the uptime question sharper than it is for a batch provider: if the LPU endpoint stalls, your user-facing latency budget is already blown.
This guide separates three things that get conflated constantly: what Groq commits to contractually, what Groq delivers in practice, and what you are able to promise downstream. They are different numbers, and only one of them is under your control.
The short version
Groq does not publish a self-serve uptime guarantee with service credits. A contractual availability percentage exists on enterprise agreements, not on a pay-as-you-go key. Everything below is about how to work with that instead of around it.
What Groq Commits To, by Tier
Availability commitments track your commercial relationship, not the technology. The same endpoint serving the same model carries a different obligation depending on which agreement you signed.
| Tier | Availability commitment | Appropriate for |
|---|---|---|
| Free tier | No published availability commitment. Capacity is best-effort and can be shed first under load. | Prototypes only |
| Pay-as-you-go / Developer | Commercial terms, but availability is generally governed by the standard online terms rather than a negotiated uptime number. | Production with a fallback |
| Enterprise / dedicated capacity | This is the tier where a contractual uptime percentage and service credits are actually negotiable. | Contractual guarantee needed |
Verify the current terms directly with Groq before you rely on any of this commercially — provider terms change, and the version you signed is the one that governs.
Convert an Uptime Percentage Into Real Downtime
Percentages hide how little room a serious target leaves you. Before you write a number into a customer contract, convert it into the minutes you would have to detect, diagnose and recover in.
| SLA | Daily | Monthly | Yearly |
|---|---|---|---|
| 99% | 14m | 7h 12m | 3d 15h 36m |
| 99.5% | 7m | 3h 36m | 1d 19h 48m |
| 99.9% | 1m | 43m | 8h 46m |
| 99.95% | 43.2s | 22m | 4h 23m |
| 99.99% | 8.6s | 4m | 53m |
| 99.999% | 0.9s | 25.9s | 5m |
The practical read: at 99.9% you have roughly 43 minutes a month, which a single bad deploy can consume. At 99.99% you have about four minutes — no human-in-the-loop response fits in that window, so the recovery has to be automatic. If your Groq integration has no automatic failover, do not promise four nines.
Declared Uptime vs Observed Uptime
A provider status page is a publishing decision, not a measurement. groqstatus.com reflects incidents Groq has chosen to declare, after an internal threshold has been crossed and confirmed. Your users experience something narrower and earlier: the requests you sent, from your region, to the specific models you call.
The gap between those two is where most real incidents live. The typical Groq failure mode is sustained p99 latency spikes and 503s on the hottest models rather than a full-region blackout — which frequently never becomes a status-page entry at all, while still breaking your product for the users who hit it.
- Declared uptime — what groqstatus.com reports. Useful for postmortems, useless for alerting.
- Observed uptime — success rate of your own synthetic requests. This is the number your SLA math needs.
- Effective uptime — the share of user requests that got a usable answer, including ones your fallback path rescued. This is what your customers actually feel.
Effective uptime is the only one of the three you can improve without Groq doing anything, which is why it is the one worth engineering against.
Alert Pro
14-day free trialStop checking — get alerted instantly
Next time Groq goes down, you'll know in under 60 seconds — not when your users start complaining.
- Email alerts for Groq + 9 more APIs
- $0 due today for trial
- Cancel anytime — $9/mo after trial
How to Measure Your Own Groq Availability
- Probe the endpoint you actually call. A health check against the marketing site tells you nothing about the API. Send a real, minimal completion request against the production model.
- Set a timeout that reflects your product. A response that arrives after your user gave up is downtime even though it returned 200. Count anything over your latency budget as a failure.
- Separate the error classes. 429 is your quota, 401 is your key, 5xx and timeouts are the provider. Only the third class belongs in an availability number.
- Probe from more than one region. Single-region monitoring turns your own network problems into false outages and misses regional degradation entirely.
- Retain the raw request log. Timestamps and status codes are the evidence any future credit claim or customer postmortem depends on. Aggregated dashboards are not evidence.
This is exactly what API Status Check does continuously for Groq and the rest of your provider stack — independent probes, per-error-class breakdowns, and a retained history you own rather than one the provider curates.
What You Can Promise Downstream
A single-provider dependency caps your achievable availability at your provider's. You cannot commit to more than your weakest link — unless you remove the single point of failure. Composite availability is multiplicative: two independent 99.9% dependencies in series give you about 99.8%, not 99.9%.
Two providers in parallel invert that math. If either can serve the request, your availability approaches the probability that both fail simultaneously, which for independent providers is small enough to change what you can honestly sign.
Before you sign an uptime commitment
- Confirm a fallback provider is configured, credentialed, and tested — not just documented.
- Define the degraded response your product returns when every provider fails. Failing soft beats a 500.
- Exclude scheduled maintenance and your own deploys explicitly, the way real SLAs do.
- Make sure your monitoring can prove the number you signed, before you need to.
Failover Targets for Groq
A fallback only helps if it fails independently. A second key on the same provider shares the same control plane and the same bad day.
Together AI
Independent control plane and capacity pool. A viable failover target when Groq availability drops below your own commitment.
Check Together AI status →Mistral
Independent control plane and capacity pool. A viable failover target when Groq availability drops below your own commitment.
Check Mistral status →OpenAI
Independent control plane and capacity pool. A viable failover target when Groq availability drops below your own commitment.
Check OpenAI status →Keep the fallback warm. A failover path that has not served a real request in three months is a hypothesis, not a mitigation.
Frequently Asked Questions
Does Groq have a published uptime SLA?
Groq does not advertise a public uptime percentage on its self-serve tiers the way a cloud provider publishes one for compute. A contractual availability commitment with service credits is something you negotiate on an enterprise agreement. If you are on a free or pay-as-you-go key, treat the practical availability as high but uncommitted, and design a fallback path rather than relying on a guarantee that is not in your contract. Always read the current terms at the time you sign — provider terms change, and a blog post is not a contract.
What uptime does Groq actually deliver in practice?
The honest answer is that only measured data tells you. groqstatus.com shows Groq-declared incidents, but provider status pages under-report short degradations and are updated by the provider, not by you. The number that matters for your own SLA math is the availability your requests observe from your region, on the models you actually call. Measure it independently and you will usually find the gap between declared and observed uptime is where your incidents live.
What does 99.9% uptime mean in real downtime for Groq?
99.9% allows about 43 minutes of downtime per 30-day month, or roughly 8 hours 45 minutes per year. 99.95% halves that to about 21 minutes a month. 99.99% allows about 4 minutes 20 seconds a month, which is less time than most teams need to notice an incident, let alone respond to it. Use the calculator on this page to convert any target into minutes before you commit to it in a customer contract.
Can I promise my customers an SLA if Groq does not give me one?
You can, but only if your architecture — not your provider — is what backs the promise. A single-provider dependency caps your achievable availability at whatever Groq delivers, and you cannot commit to more than your weakest link. Teams that promise uptime on top of an LLM API do it with a second provider configured for failover, aggressive timeouts, cached or degraded responses, and a circuit breaker that fails soft instead of returning a 500.
How do I claim service credits for Groq downtime?
Service credits only exist where a contract creates them, so this applies to enterprise agreements. Where they do exist, credits are almost never automatic — you have to file a claim within a defined window, usually 30 days, with evidence of the failed requests. That evidence has to be your own monitoring data with timestamps and error codes; a screenshot of the provider's status page is not a claim. This is the single most common reason otherwise valid credit claims are denied.
Related Guides
Measure the Uptime You Are Actually Getting
Groq will not send you an availability report. API Status Check probes Groq and every other provider in your stack independently, so the number you quote your customers is one you can prove.
Start Your Free Trial →🌐 Can't Access Groq?
If Groq is working for others but not for you, it might be an ISP or regional issue. A VPN can help bypass network-level blocks and routing problems.
Troubleshoot with a VPN
Connect from a different region to test if the issue is local to your network. Also protects your connection on public Wi-Fi.
Try NordVPN — 30-Day Money-Back GuaranteeSecure Your Groq Account
Service outages are a common time for phishing attacks. Use a password manager to keep unique, strong passwords for every account.
Try NordPass — Free Password Manager⏳ While You Wait — Try These Alternatives
🛠 Tools We Use & Recommend
Tested across our own infrastructure monitoring 200+ APIs daily
SEO & Site Performance Monitoring
Used by 10M+ marketers
Track your site health, uptime, search rankings, and competitor movements from one dashboard.
“We use SEMrush to track how our API status pages rank and catch site health issues early.”