GCP Cloud Run SLA Credits & Refunds Guide
How the GCP Cloud Run SLA works: uptime tiers, exclusions, claim windows, and how to recover the credits you're owed when Cloud Run goes down.
GCP Cloud Run SLA Credits & Refunds
Cloud Run on GCP is covered by Google's standard service-credit framework, but the per-product thresholds vary and the claim process is documented in pieces across Cloud Support and the SLA terms. Here's the consolidated Cloud Run version: uptime targets, exclusions, and how to recover credits without grinding through a multi-week support thread.
What this guide covers
- The official GCP Cloud Run uptime commitment and credit tiers
- Which incidents qualify (and which exclusions silently disqualify claims)
- How to file a Cloud Run credit request inside the GCP claim window
- Why manual claim recovery typically leaves money on the table
Frequently asked questions about GCP Cloud Run SLAs
What is the typical SLA uptime guarantee for GCP Cloud Run?
Google commits to a 99.95% monthly uptime percentage for Cloud Run services that have at least one container instance ready to serve traffic. If Google fails to meet this commitment during a billing cycle, you are eligible to receive a portion of your Cloud Run spend back as a service credit.
How do I claim GCP Cloud Run SLA credits after an outage?
File a Financial Credit Request through Google Cloud Support within 30 days of the end of the affected billing month — the deadline is shorter than AWS or Azure, which catches a lot of teams out. Include your Project ID, the affected Cloud Run resources, downtime intervals (with timezone), supporting evidence from Cloud Monitoring or your own observability stack, and a calculation showing where Monthly Uptime Percentage fell below the SLA threshold. Google issues approved credits against your billing account, not as cash refunds.
What exclusions apply to the GCP Cloud Run SLA?
Specifically for Cloud Run, cold-start latency, container startup probe failures from your application image, and revisions configured with min-instances of 0 that experience first-request delays are explicitly not covered — only platform-side request-routing or invocation failures qualify.
Why is it difficult to get refunds for Cloud Run outages manually?
Compute outages rarely show up cleanly. A Cloud Run workload might be partially degraded — some instances fail, others stay healthy — and the SLA only counts the portion of capacity that was actually unavailable. To prove a claim you need per-instance (or per-task) error-rate data, not just an aggregate dashboard. Most teams discover this only when their first credit request comes back denied for "insufficient evidence."
Related GCP SLA guides
Other Google Cloud services with their own published SLA and 30-day claim window:
- GCP Compute Engine SLA credits — Compute
- GCP Cloud Functions SLA credits — Compute
- GCP GKE SLA credits — Compute
- GCP Cloud Storage SLA credits — Storage
Don't miss GCP's 30-day claim window
GCP's claim deadline for Cloud Run is the shortest of the three major clouds, and most teams miss it for the same reason: nobody owns "file SLA credit requests" as a recurring task. By the time finance closes out the month, the window is already gone.
Next Signal monitors Cloud Run availability, files the Financial Credit Request inside Google's deadline, and tracks the claim through resolution. See how it works or start a free trial.
Related SLA guides
Other GCP services with their own SLA credit recovery process.