Elevated query errors for Grafana Cloud Metrics in prod-us-east-3
Grafana Cloud Metrics queries fail for some customers in prod-us-east-3. The query errors have stopped, and Grafana Cloud monitors the service to confirm it stays stable.
State
Monitoring
Started
Ongoing for
30 min
Worst impact
Degraded
Timeline
1 updateMonitoring
30 min 100%
Updates
Times in UTCAs posted by Grafana Cloud
Between 17:21 and 17:41 UTC, a small percentage of metrics queries for some Grafana Cloud Metrics customers in the prod-us-east-3 region failed. Ingestion was not affected. Query errors have stopped, and we are monitoring the service to confirm it stays stable.
Grafana Cloud in the last 90 days
Full historyIncidents in 90 days
56
Days with an incident
44
Median duration
2 h 45 min
This incident
82% shorter than the median
Other Grafana Cloud incidents
All incidentsGrafana Cloud·Degraded performance for Grafana Cloud Metrics in prod-us-central-7
Grafana Cloud Metrics, Logs, and Traces do not work correctly in the prod-us-central-7 region. Some customers can see failed or delayed writes, query errors, and failed alerting and recording rule evaluations. Grafana Cloud is investigating the issue.
Grafana Cloud·Cloud Logs writes - Elevated latency and error rates in prod-eu-central-0
Grafana Cloud Cloud Logs writes had high latency and error rates in prod-eu-central-0. The affected components were AWS Switzerland - prod-eu-central-0 and Logs - AWS Switzerland - prod-eu-central-0. Grafana Cloud reports that this incident is resolved, and it lasted about 17 minutes.
Grafana Cloud·Mimir query unexpected response with status code 500
Grafana Cloud Metrics queries failed for some customers in AWS US East (OH) and GCP US Central. The errors occurred when customers read older data. Grafana Cloud reports that the service fully recovered and the incident is resolved.
Grafana Cloud·Synthetic Monitoring — Jakarta Public Probe Degradation
Between 08:31 and 09:17 UTC on 6 November 2026, a network issue at the Jakarta public probe caused elevated check failures for monitors running from that location. - DNS checks: failure rate increased from ~0.3% to ~15% - HTTP, ping, traceroute, and browser checks: <1% failure rate - Browser checks: some delays and retries observed - TCP checks: not affected - All other probe locations: not affected
Grafana Cloud·GitHub returning 403 for all Git Sync repositories
Grafana Cloud Git Sync repositories showed as unhealthy and syncs were skipped in all listed AWS regions. The provider identified the problem, deployed a fix to all production clusters, and monitored the result. Grafana Cloud resolved the incident after 1 hour and 58 minutes.
Follow Grafana Cloud
Your coding agent knows when Grafana Cloud is down, and tells you when a failure is theirs, not yours. You can also get Grafana Cloud incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.live/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "grafana" and tell me if Grafana Cloud has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.live/feed.xml?providers=grafana/feed subscribe https://outages.live/feed.xml?providers=grafanaFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane