Skip to content
🎉 Launch sale:50% off everything over $22 — automatically applied at checkout· ends Aug 2Shop the sale →
DevOps AI ToolKit
Newsletter
All guides
GCP with AI By James Joyner IV · · 9 min read Last reviewed Jul 2026

GCP Error Guide: 'The billing account for the owning project is disabled' — Re-enable Billing

Quick answer

Fix 'The billing account for the owning project is disabled in state absent' on GCP: re-link a valid billing account, resolve closed or over-budget accounts, and check IAM.

  • #gcp
  • #cloud
  • #troubleshooting
  • #errors
Free toolkit

Stuck on this GCP with AI error? Get the free incident triage checklist

A one-page PDF — the exact steps to isolate, fix, and verify a production error like this one. No spam, unsubscribe anytime.

Overview

Almost every Google Cloud API call that creates or runs a billable resource checks that the project has an active billing account behind it. When that link is broken, the API returns HTTP 403 with reason billingNotEnabled and a message like this:

ERROR: (gcloud.compute.instances.create) Could not fetch resource:
 - The billing account for the owning project is disabled in state absent

The REST/JSON form is the same failure wearing a different shape:

{
  "error": {
    "code": 403,
    "message": "The billing account for the owning project is disabled in state absent.",
    "status": "PERMISSION_DENIED",
    "errors": [{ "reason": "billingNotEnabled" }]
  }
}

It is easy to confuse this with a plain IAM PERMISSION_DENIED or with SERVICE_DISABLED, but the billingNotEnabled reason and the phrase “billing account … is disabled” are the tell: the problem is the money link, not the permission or the API toggle.

Symptoms

  • gcloud create commands and Terraform apply fail with billingNotEnabled / “billing account … is disabled”.
  • Existing Compute Engine VMs get stopped and new ones will not start; Cloud Run and GKE workloads stop scheduling.
  • The Cloud Console shows a red “Billing is disabled for this project” banner.
  • gcloud billing projects describe PROJECT_ID reports billingEnabled: false or an empty billingAccountName.
  • The state descriptor varies — in state absent (no account linked), in state closed (account was closed), or in state delinquent (unpaid / over budget) — each pointing at a different root cause.

Common Root Causes

  • No billing account linked — the project was created (often by API or Terraform) without ever attaching billing; state shows absent.
  • Billing account closed — the linked account was manually closed or auto-closed; state shows closed.
  • Payment failure or delinquency — a declined card or expired payment instrument suspended the account; state shows delinquent.
  • Free trial ended — the trial credits expired and no paid account replaced them, so billing was disabled.
  • Budget action / automation — a Cloud Billing budget wired to a Cloud Function that unlinks billing on overspend actually fired.
  • Insufficient IAM to re-link — the caller lacks roles/billing.user on the account or roles/resourcemanager.projectBillingManager on the project, so re-enabling silently isn’t possible for them.
  • Org policy / account suspension — the whole billing account is suspended at the organization level (abuse, verification, or admin action).

Diagnostic Workflow

Start by confirming whether billing is actually enabled and which account is linked:

gcloud billing projects describe PROJECT_ID

Look at billingEnabled and billingAccountName. If enabled is false or the account name is empty, that is your answer.

List the billing accounts you can see and their open/closed status:

gcloud billing accounts list

OPEN: True means the account is usable; OPEN: False means it is closed and cannot be linked until reopened.

Confirm you have the rights to change the link:

gcloud billing accounts get-iam-policy BILLING_ACCOUNT_ID
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --filter="bindings.role:roles/resourcemanager.projectBillingManager"

Check whether a budget-driven automation may have unlinked billing:

gcloud billing budgets list --billing-account=BILLING_ACCOUNT_ID
gcloud logging read 'resource.type="cloud_function"
  AND textPayload:"updateBillingInfo"' --limit=20 --project=PROJECT_ID

If nothing looks closed and you have rights, inspect recent billing changes in the audit log:

gcloud logging read 'protoPayload.serviceName="cloudbilling.googleapis.com"' \
  --project=PROJECT_ID --limit=20 --format='table(timestamp, protoPayload.methodName, protoPayload.authenticationInfo.principalEmail)'

Example Root Cause Analysis

A team’s nightly Terraform run began failing every VM creation with billing account ... is disabled in state closed. IAM looked fine, so the on-call engineer first suspected a permission regression.

gcloud billing projects describe showed billingEnabled: false with the old account still named. gcloud billing accounts list revealed that account as OPEN: False. The billing audit log (cloudbilling.googleapis.com, method UpdateBillingAccount) showed a finance admin had closed the account two days earlier during a cost-center reorg, not realizing three active projects were still linked to it.

The fix was to link the projects to the new, open billing account:

gcloud billing projects link PROJECT_ID --billing-account=NEW_BILLING_ACCOUNT_ID

VMs started again immediately. The lasting fix was process, not code: the finance team added a “list linked projects before closing” step, and the platform team added a Cloud Monitoring alert on billingEnabled flipping to false.

Prevention Best Practices

  • Alert on billing state — watch for billingEnabled: false (via a scheduled gcloud billing projects describe check or billing export) and page before workloads stop.
  • Keep a healthy payment instrument — set a backup card and enable payment-failure notifications so delinquency never sneaks up.
  • Be careful with budget automations — a budget-triggered function that unlinks billing is a foot-gun; prefer alert-only budgets, and if you must cap spend, scope the automation tightly and test it.
  • Guard billing IAM — restrict who holds roles/billing.admin; require a check for linked projects before anyone closes an account.
  • Link billing at project creation — bake gcloud billing projects link (or the Terraform google_billing_project_info / project-factory) into project bootstrap so no project is ever absent.
  • Separate finance and platform ownership — make sure closing an account requires visibility into who depends on it.

Quick Command Reference

# Is billing enabled and which account is linked?
gcloud billing projects describe PROJECT_ID

# Which billing accounts can I use, and are they open?
gcloud billing accounts list

# Re-link the project to a valid, open billing account
gcloud billing projects link PROJECT_ID --billing-account=BILLING_ACCOUNT_ID

# Confirm I can manage billing on the project
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --filter="bindings.role:roles/resourcemanager.projectBillingManager"

# Look for a budget automation that unlinked billing
gcloud billing budgets list --billing-account=BILLING_ACCOUNT_ID

# Audit recent billing changes
gcloud logging read 'protoPayload.serviceName="cloudbilling.googleapis.com"' \
  --project=PROJECT_ID --limit=20

Conclusion

“The billing account for the owning project is disabled” is a billing-link failure, not a permission or API-enablement problem — the billingNotEnabled reason and the absent / closed / delinquent state word tell you exactly which. Confirm the state with gcloud billing projects describe, find an open account with gcloud billing accounts list, re-link with gcloud billing projects link, and then close the loop with an alert on billingEnabled and tighter billing-admin controls so a single account closure never silently takes your workloads offline again.

Free download · 368-page PDF

Fixed it? Get 500 GCP with AI & DevOps AI prompts — free

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.

Did this fix your issue?

Free download · 368-page PDF

Get 500 Battle-Tested DevOps AI Prompts — Free

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.