GCP Cloud Monitoring Dashboards: Create, Use, and Manage Custom Dashboards

What is a Cloud Monitoring dashboard?

A dashboard is a collection of charts and panels arranged on one screen. Each panel shows a different metric or view: request rate, error count, latency percentiles, active instances, recent logs. Together they give you a complete picture of how a service is behaving right now.

Without a dashboard, every investigation starts from scratch. You open Metrics Explorer, pick a metric, apply a filter, and look at one chart in isolation. A dashboard pins those queries so you always see them together, in context, without reconstructing them each time.

Why dashboards matter

Dashboards are useful in three situations:

• During an incident. A team that opens one dashboard and immediately sees what is wrong moves faster than one rebuilding queries under pressure. Build your dashboard before you need it.
• For routine health checks. Glancing at a dashboard before and after a deployment shows whether key metrics stayed stable.
• For onboarding. A new engineer looking at a service’s dashboard quickly learns what the service does, what its dependencies are, and what normal behavior looks like.

Alerting policies tell you when something is wrong. Dashboards show you exactly what is happening once you know something is wrong. Both are necessary, and they work best together.

Predefined dashboards vs custom dashboards

Cloud Monitoring includes two types of dashboards:

Predefined dashboards are automatically available for services like Cloud Run, GKE, Cloud SQL, and Pub/Sub. They cover the most useful built-in metrics for each service without any setup, and they are read-only.

How Cloud Monitoring dashboards work

Widgets

A dashboard is made up of widgets. Each widget shows one type of data. You add as many widgets as you need and arrange them in a grid layout. The widget type determines what kind of data it can display and how.

Time range

Dashboards have a global time range selector in the top right. All charts on the dashboard update when you change the time range. The default is the last hour. When investigating something older, update the time range before concluding the dashboard shows nothing.

Filters

Dashboards support dashboard-level filter variables. You can add a filter like service_name or cluster, and every widget that uses that label updates when you change the filter value. This lets a single dashboard template serve multiple services.

Metrics scope and multi-project visibility

Dashboards live in a specific GCP project. If your organization uses a metrics scope where one monitoring project aggregates data from multiple projects, create your dashboards there. You can then display metrics from dev, staging, and prod in one view without switching projects.

Access and permissions

Dashboard access is controlled through IAM at the project level. roles/monitoring.viewer allows reading dashboards. roles/monitoring.editor allows creating and editing them. There is no per-dashboard permission. See IAM Roles for how monitoring roles fit into broader GCP access control.

How to create a custom dashboard

In the GCP Console, navigate to Monitoring > Dashboards > Create Dashboard.

Before adding widgets, decide:

• What service or system does this dashboard represent?
• Who will use it, and what questions do they need answered?
• Should it cover one project or a scoped multi-project view?

Then add widgets one at a time. For each widget, choose the type, select a metric (or write a query), and configure aggregation, grouping, and filters. The dashboard auto-saves as you edit.

Dashboard widget types and when to use each

The time series chart is the most versatile. Use it for anything that changes over time. Scorecards and gauges work best for single current-value metrics. The alert/incidents widget should go at the very top of any incident dashboard so open incidents are always visible when you open the page.

The log panel is underused but valuable. Embedding a filtered log view directly in a dashboard means you can correlate log output with metric spikes without switching to Logs Explorer. For a Cloud Run service, filter it to severity=ERROR and the service name. It takes two minutes to add and saves significant time during incidents.

Recommended layout for a service dashboard

For any service running in production, build a dashboard that answers these questions at a glance: Is it running? Is it healthy? Are resources constrained? What happened recently?

1. Alert list at the top. Open incidents are immediately visible when you land on the page.
2. Request rate. Requests per second, grouped by response code class (2xx, 4xx, 5xx).
3. Error rate. 5xx responses as a count or percentage.
4. Latency. p50, p95, and p99 on the same chart.
5. Instance or replica count. How many instances are currently running.
6. CPU and memory utilization. Are resources near saturation?
7. Log panel. Recent errors from Cloud Logging for the service.

For Cloud Run, see Monitoring Cloud Run for the exact metric names and a worked example. For GKE workloads, see Monitoring GKE for node, pod, and container-level metrics to include alongside the standard service view.

Query options for dashboard charts

When you add a time series chart, you choose how to specify the metric. There are three options.

Metric filter / query builder (default)

The default option in the GCP Console. You select a metric type, then apply label filters and configure aggregation using dropdowns. This is the right starting point and covers the majority of dashboards. Only reach for a query language if the filter builder cannot express what you need.

PromQL

PromQL is available in Cloud Monitoring charts when querying Prometheus metrics collected via Managed Service for Prometheus. If your GKE workloads emit Prometheus-format metrics, PromQL is the right tool for querying them. The syntax uses label selectors and rate functions that will feel familiar if you have used Grafana or open-source Prometheus.

rate(http_requests_total{job="api-service", code=~"5.."}[5m])
/
rate(http_requests_total{job="api-service"}[5m])

MQL (Monitoring Query Language)

MQL is a pipe-based language for querying Cloud Monitoring native metrics. It predates the current console UI and was once the primary path for advanced queries. New dashboards in the console no longer default to MQL. However, existing MQL dashboards and charts continue to work, and MQL is still supported through the API and Terraform.

fetch cloud_run_revision
| metric 'run.googleapis.com/request_count'
| filter metric.labels.response_code_class == '5xx'
| align rate(1m)
| every 1m

PromQL vs MQL at a glance

Dashboards as code

Cloud Monitoring dashboards are stored as JSON. That JSON can be exported, version-controlled, and deployed to other projects, making dashboards reproducible and eliminating the problem of a manually-built dashboard that exists only in one project.

gcloud

# List dashboards
gcloud monitoring dashboards list --project=my-app-prod

# Export a dashboard as JSON
gcloud monitoring dashboards describe DASHBOARD_ID \
  --project=my-app-prod \
  --format=json > dashboards/api-service.json

# Create a dashboard from a JSON file
gcloud monitoring dashboards create \
  --config-from-file=dashboards/api-service.json \
  --project=my-app-prod

Terraform

Use the google_monitoring_dashboard resource. The recommended workflow: build the dashboard in the console, export it as JSON with gcloud, then reference that file in Terraform. See Terraform for Google Cloud for how to structure GCP Terraform projects.

resource "google_monitoring_dashboard" "api_service" {
  dashboard_json = file("${path.module}/dashboards/api-service.json")
}

API

The Cloud Monitoring REST API supports full CRUD for dashboards at projects.dashboards. This is useful for programmatic dashboard management in CI/CD pipelines or scripts that create dashboards dynamically.

When to use dashboards

• Incident response. Open the dashboard immediately when an incident starts. A good dashboard shows whether the problem is traffic-related, resource-related, or a specific error type within seconds.
• Post-deployment verification. Check request rate, error rate, and latency before and after a deployment to confirm the change is stable.
• Capacity planning. Track instance count, CPU, and memory trends over weeks to anticipate when you will need to scale.
• Team onboarding. Point new engineers to the service dashboard first. Seeing real metrics from a live service is faster than reading documentation.

Dashboards vs Metrics Explorer

Metrics Explorer is where you go when you do not know what you are looking for yet. A dashboard is what you build once you know which metrics matter and want them always at hand. For routine operations, dashboards win. For open-ended investigation, start in Metrics Explorer, then promote the queries that prove useful into a permanent dashboard.

Dashboards and alerting policies are also complementary. Alerts tell you when to look. Dashboards show you what to look at.

Common beginner mistakes

Mistake 1: building dashboards after an incident

During an incident is not the time to figure out which metric to query. Build your core service dashboard before you go to production. It should already exist when things go wrong so you can focus on diagnosing, not querying.

Mistake 2: too many charts on one dashboard

A 30-widget dashboard is slow to load and overwhelming to read. Keep dashboards focused: one per service, with only the metrics you actually look at. Build separate dashboards for high-level health and detailed deep-dives.

Mistake 3: forgetting to change the time range

Dashboards default to the last hour. When investigating something from 6 hours ago, update the time range first before concluding the dashboard shows nothing. The selector is in the top right corner.

Mistake 4: not exporting dashboards to code

A manually-built dashboard can be accidentally deleted or exist only in one project. Export dashboard JSON, check it into version control, and manage it with Terraform. This takes 10 minutes and eliminates a painful class of loss.

Mistake 5: duplicating dashboards instead of using filter variables

If you copy one dashboard for five services by duplicating it and hardcoding service names, you now have five dashboards to update whenever you add a widget. Use dashboard-level filter variables instead so one template covers all services.