Is Google Cloud down?
Use this page to distinguish a broad Google Cloud incident from a problem limited to a product, API, region, project, identity, network, or application. Check the official status dashboard first, then compare its scope and timing with your failed requests and logs.
Site Administrator
Last reviewed: September 25, 2026
LATEST RECORDED STATUS
Up Google Cloud’s website appeared to be up and responding normally at the last check.
| Endpoint | Status | Observed |
|---|---|---|
| cloud.google.com | Operational | 2026-11-09 12:33 UTC |
Is it working for you?
0 recent reports — more reports are needed for a useful trend.
For the full picture, including partial or regional outages a single external check may miss, see Google Cloud’s official status page. official status page.
What this check can tell you
- Check the Google Cloud Status Dashboard before changing production configuration.
- Match the affected product, API, region, project, operation, and first-failure time against any reported incident.
- A failure in one project or API does not by itself indicate that Google Cloud is broadly unavailable.
- Compare the same request from another network or authenticated environment to separate local connectivity from service-side errors.
- For API failures, record the endpoint, HTTP status, response body, project, region, timestamp, and request or correlation ID when available.
- Follow documented retry behavior; repeated non-idempotent writes can create duplicate operations or obscure the original failure.
About Google Cloud reliability
Understanding Google Cloud availability
Google Cloud includes many products, APIs, regions, projects, and infrastructure services. An incident affecting one API or region may leave the Cloud Console and unrelated services working normally. Conversely, a working Console does not prove that a VM, deployment, database, API endpoint, or application is healthy.
Use the Google Cloud Status Dashboard to check reported incidents and service-specific availability notices. Compare each notice with the affected product, operation, region, project, and the time your errors began.
If no matching incident is listed, investigate the narrower scope of the failure. Permissions, billing, quotas, enabled APIs, organization policies, credentials, DNS, firewall rules, proxies, and application configuration can all cause Google Cloud errors without indicating a platform-wide outage.
How to troubleshoot Google Cloud
Troubleshooting Google Cloud problems
Check for a reported incident
Open the Google Cloud Status Dashboard and look for an incident matching the affected product or API, region, operation, and time the problem started. If the scope matches, avoid unnecessary configuration changes and follow the incident updates.
A status page cannot rule out an issue confined to a project, account, resource, quota, or application. If there is no matching notice, continue with the narrower checks below.
Separate platform, regional, project, and resource failures
- If multiple unrelated Google Cloud products and projects fail at the same time, a broader platform or network problem is more plausible.
- If only one region, project, API, resource, deployment, or operation fails, investigate that scope before treating the event as global.
- If the Cloud Console works but an application request fails, focus on the specific API, endpoint, credentials, quota, firewall path, and application logs.
- If only one user is affected, check that user’s account, permissions, organization policy, and selected project.
Check project, identity, billing, and quota configuration
Confirm that the request uses the intended Google Cloud account and project. Check that the required API is enabled, the identity has the necessary permissions, billing is configured as expected, and the project has not reached a quota or resource limit. Compare with a known-good project or identity only when the comparison is safe and authorized.
Investigate Cloud Console and browser issues
For a Console-only problem, try a private window, another supported browser, or another network. Temporarily rule out extensions, stale session data, and an expired login session. If the issue follows the account rather than the browser, investigate identity, organization policy, permissions, or project selection instead of repeatedly clearing browser data.
Investigate network, DNS, and TLS failures
If the Console or API cannot be reached, compare browser access with an application or command-line request and, where authorized, test from another network. Inspect proxy, VPN, firewall, egress, DNS, and certificate behavior. A timeout, connection refusal, DNS failure, or TLS error requires a different path from an API response reporting authorization, quota, or invalid-request errors.
Relevant guides:
- [ERR_CONNECTION_TIMED_OUT](/guides/err-connection-timed-out)
- [ERR_CONNECTION_REFUSED](/guides/err-connection-refused)
- [DNS_PROBE_FINISHED_NXDOMAIN](/guides/dns-probe-finished-nxdomain)
- [ERR_SSL_PROTOCOL_ERROR](/guides/err-ssl-protocol-error)
Investigate API and application errors
Capture the full HTTP status, response body, endpoint, region, project identifier, timestamp, and request or correlation ID when available. Check application logs and the relevant Google Cloud product’s operation or deployment status. Separate authentication and authorization failures from invalid arguments, rate limits, unavailable services, gateway errors, and client-side timeouts.
Retry only according to the relevant API or client’s documented behavior. Use backoff for transient failures where appropriate, and do not blindly retry non-idempotent writes.
Related troubleshooting guides
TROUBLESHOOTING GUIDE
500 Internal Server Error
A 500 Internal Server Error means the server encountered an unexpected problem while processing the request. The browser usually cannot identify the cause, so start by matching the failure time with PHP, application, and web-server logs. Recent code, plugin or theme changes, `.htaccess` rules, permissions, resource limits, and deployment settings are common causes.
TROUBLESHOOTING GUIDE
502 Bad Gateway
A 502 Bad Gateway means a reverse proxy, load balancer, or CDN could not obtain a valid response from the backend server. Check the backend process, proxy error log, upstream host or port, socket permissions, resource limits, and CDN-to-origin access. The fault is usually between servers rather than in the browser.
TROUBLESHOOTING GUIDE
503 Service Unavailable
A 503 Service Unavailable response means the service cannot handle the request at that time. Common causes include exhausted CPU, memory, worker, or connection capacity; incomplete maintenance mode; an unavailable database or other dependency; or a proxy, WAF, rate limiter, or load balancer returning 503. Identify which layer generated the response, then review logs and resource usage before changing settings.
TROUBLESHOOTING GUIDE
504 Gateway Timeout
A 504 Gateway Timeout means a proxy, CDN, load balancer, or gateway waited for a backend response but its timeout expired first. The backend may still be running; common causes include slow database queries, overloaded workers, long-running tasks, delayed third-party services, and restrictive intermediary timeouts. Compare direct backend timing with the full gateway path before changing timeout settings.
TROUBLESHOOTING GUIDE
ERR_CONNECTION_TIMED_OUT
`ERR_CONNECTION_TIMED_OUT` means the browser waited for the destination server or an intermediary to respond, but no usable response arrived before the connection timeout. Common causes include an unreachable or overloaded server, a firewall silently dropping traffic, incorrect DNS, a broken network route, or a CDN or proxy that cannot reach the origin. Test from another network first, then check DNS, infrastructure health, firewall rules, and resource usage.
Sources & references
Official source
- Google Cloud Status Dashboard — Check reported Google Cloud incidents and service availability information.
Use the dashboard to compare incident scope and timing with your symptoms. For environment-specific details, consult the relevant Google Cloud product documentation and review your project, application, and network logs.
How this check works
Every time this page loads, our server makes its own request to cloud.google.com (and its API domain, when applicable) and reports what it got back — a real HTTP response, a timeout, or a connection failure. That result is cached for up to 2 minutes.
This confirms external reachability; it does not test every feature, region, account, or network path. Cross-check the official status page when one is available.
Embed this live status badge
Add this badge to a dashboard, documentation page, or blog. The badge reads the cached Erriscope observation and links back to this status page.
<a href="https://erriscope.com/status/google-cloud/"><img src="https://erriscope.com/status/badge/google-cloud.svg" alt="Google Cloud status on Erriscope" width="210" height="34"></a>Frequently asked questions
Is this the same as Google Cloud's official status page?
No. This is a live, one-off connectivity check run from our own server, not Google Cloud's own incident reporting. Their official status page can show partial, regional, or component-level issues our single external check cannot detect.
Why does this show "Up" when Google Cloud feels slow or broken for me?
A basic reachability check confirms that the server responded to our request. It does not test every feature, region, ISP, browser, or account-specific issue.
How often is this checked?
A check is refreshed after the two-minute cache expires. The displayed check time shows when the observation was made.
Does an API outage mean the whole product is down?
Not necessarily. Many services split their website and API onto separate infrastructure, so one can fail while the other keeps working.
How do I check whether Google Cloud is down?
Check the Google Cloud Status Dashboard for an incident affecting the product, API, or region you use. Compare the incident’s scope and start time with your own errors before concluding that the failure is platform-wide.
Why does the Google Cloud Console work while my API request fails?
The Console and API request may use different services, credentials, endpoints, permissions, projects, and regions. Check the API response, selected project, authentication, enabled API, quota, network path, and application configuration.
Why is only one Google Cloud project affected?
A project-only failure can result from permissions, billing, quotas, enabled APIs, organization policies, resource configuration, or a deployment. It is not by itself evidence of a Google Cloud-wide outage.
What should I record when reporting a Google Cloud failure?
Record the affected product and operation, project and region, exact error and HTTP status, first-failure time, frequency, client or network used, and any request or correlation ID in the response or logs. Remove secrets and sensitive data before sharing diagnostics.
Should I keep retrying a failed Google Cloud request?
Not automatically. Follow the relevant API or client’s retry guidance. Transient read failures may be retryable with backoff, but repeated non-idempotent writes can create duplicate operations or make diagnosis harder.
What if the Google Cloud Status Dashboard shows no incident?
Test from another network or authenticated environment and check project selection, permissions, billing, quotas, API configuration, DNS, firewall, proxy, and application logs. An issue limited to your project, region, account, resource, or network may not appear as a platform-wide incident.
This is a live connectivity check from our server, not an official statement from Google Cloud. A down result may also reflect a regional or partial outage.
LIVE CHECKS
