SERVICE_DISABLED
GCP SERVICE_DISABLED means the target Google Cloud API is disabled for the consumer project, so requests are rejected until that service is enabled.
Last reviewed: March 5, 2026|Editorial standard: source-backed technical guidance
What Does Service Disabled Mean?
The request reached Google control planes, but the called API is not currently enabled for that project state, so execution is blocked before normal processing.
Common Causes
- -The API was never enabled in the project that owns the request quota and billing context.
- -The API was previously enabled but later disabled during cleanup, policy hardening, or project template changes.
- -The request is sent with credentials from the wrong project, where that API is still disabled.
- -Automation lacks required Service Usage permissions to enable the service during bootstrap.
How to Fix Service Disabled
- 1Read
ErrorInfodetails and capture the exactserviceandconsumervalues returned with SERVICE_DISABLED. - 2Enable the required API in the same consumer project used by the failing workload.
- 3Confirm the operator or automation identity has Service Usage enable permissions before rerunning bootstrap steps.
- 4Retry the original request after enablement propagation and verify no residual disabled-service errors remain.
Step-by-Step Diagnosis for Service Disabled
- 1Capture full error payload and verify
reason=SERVICE_DISABLED, including the affected service name. - 2Verify the effective project identity used by the workload (project ID/number and credential source).
- 3Check whether the API is enabled in that exact project and environment, not only in neighboring projects.
- 4Audit IAM on enable workflows and validate required Service Usage permissions for CI/CD identities.
Consumer Project and API State Validation
- -Match the
consumerproject from error metadata to runtime credentials (example: workload runs under project B while engineers enabled API in project A). - -Verify API state for the exact service endpoint (example:
run.googleapis.comenabled, butartifactregistry.googleapis.comstill disabled for deploy path).
Enablement Permissions and Automation Gaps
- -Validate Service Usage IAM for bootstrap actors (example: pipeline can deploy resources but lacks permissions required to enable new APIs).
- -Review infra templates for explicit API enable steps and idempotent checks before resource creation.
How to Verify the Fix
- -Re-run the same request and confirm SERVICE_DISABLED no longer appears in error details.
- -Validate dependent workflows (deploy, runtime calls, background jobs) complete without disabled-service failures.
- -Check audit and pipeline logs to confirm API enablement steps are now deterministic across environments.
How to Prevent Recurrence
- -Codify required APIs per service in infrastructure-as-code and enforce drift detection for disabled dependencies.
- -Add pre-deploy checks that fail fast when required APIs are not enabled in target projects.
- -Monitor SERVICE_DISABLED occurrences by service and project to catch configuration regressions early.
Pro Tip
- -keep a per-workload API dependency manifest and validate it in CI before first deploy to new projects.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
AWS ThrottlingException vs GCP RESOURCE_EXHAUSTED
Compare AWS ThrottlingException and GCP RESOURCE_EXHAUSTED to separate rate limiting from quota/resource exhaustion and choose the remediation path.
Playbook
Rate Limit Recovery Playbook (429 / ThrottlingException / RESOURCE_EXHAUSTED)
Use this playbook to separate transient throttling from hard quota exhaustion and apply retry, traffic-shaping, and quota-capacity fixes safely.
Official References
Provider Context
This guidance is specific to GCP services. Always validate implementation details against official provider documentation before deploying to production.