Manage Dashboards

Manage Dashboards

This skill guides agents through the full dashboard lifecycle using gcx: pulling from Grafana, pushing to Grafana, creating new dashboards, validating files, and promoting dashboards across environments. All operations work with Kubernetes-style resource files on disk.

Prerequisites

gcx must be installed and configured with a working context pointing to your Grafana instance. If gcx is not configured, use the setup-gcx skill first.

# Verify configuration and connectivity
gcx config check

---

Workflow 1: Pull Dashboards from Grafana

Pull downloads resources from Grafana and writes them as local JSON or YAML files. Use pull to create a local working copy, back up dashboards, or bootstrap a GitOps repository.

Pull all dashboards

# Pull all dashboards into ./resources (JSON, default)
gcx resources pull dashboards

# Pull as YAML
gcx resources pull dashboards -o yaml

# Pull to a custom directory
gcx resources pull dashboards -p ./my-dashboards

Pull folders and dashboards together

Pulling folders alongside dashboards preserves the folder hierarchy on disk. Always pull both when you intend to push them to another environment later.

gcx resources pull dashboards folders
gcx resources pull dashboards folders -p ./resources -o yaml

Pull a specific dashboard

# Pull by UID
gcx resources pull dashboards/my-dashboard-uid

# Pull multiple specific dashboards
gcx resources pull dashboards/uid-a dashboards/uid-b

# Pull dashboards matching a glob pattern
gcx resources pull dashboards/prod-*

Pull dashboards managed by other tools

By default, pull only fetches dashboards managed by gcx. To include dashboards created via the UI, Terraform, or other tools:

gcx resources pull dashboards --include-managed

Inspect pulled resources

After pulling, files appear in the target directory structured by kind:

./resources/
  dashboards/
    my-dashboard.json
    another-dashboard.yaml
  folders/
    my-folder.json

Use gcx resources get to inspect resources without writing files:

gcx resources get dashboards -o json
gcx resources get dashboards/my-uid -o yaml

---

Workflow 2: Push Dashboards to Grafana

Push reads local resource files and writes them to Grafana. gcx handles folder ordering automatically and protects resources managed by other tools.

Topological sort: folders are pushed before dashboards

When pushing a directory that contains both folders and dashboards, gcx automatically pushes folders first (level by level) before pushing dashboards. Dashboards reference their parent folder via spec.folderUID; the folder must exist before the dashboard can be created or updated. You do not need to split the push into two separate commands — gcx's topological sort handles ordering automatically.

# Push everything under ./resources — folders created before dashboards
gcx resources push

# Push from a specific directory
gcx resources push -p ./my-resources

# Explicitly include both kinds (still sorted automatically)
gcx resources push dashboards folders

Manager metadata

When gcx pushes a resource, it sets this annotation automatically:

metadata:
  annotations:
    grafana.app/managed-by: gcx

Resources that carry a different grafana.app/managed-by value (set by the Grafana UI, Terraform, or another tool) are protected by default. gcx refuses to overwrite them unless you pass --include-managed.

# Override protection — only when you deliberately want to take ownership
gcx resources push --include-managed

Dry run before pushing to production

Always dry-run before pushing to production environments to preview what will change:

gcx resources push --dry-run
gcx resources push -p ./my-resources --dry-run

Push specific kinds or UIDs

# Push only dashboards (folders must already exist in Grafana)
gcx resources push dashboards

# Push a single dashboard file
gcx resources push -p ./resources/dashboards/my-dashboard.json

Error handling during push

# Stop on first error (useful when later resources depend on earlier ones)
gcx resources push --on-error abort

# Continue past errors, report all failures at the end (default)
gcx resources push --on-error fail

# Ignore per-resource errors entirely (CI pipelines with partial success)
gcx resources push --on-error ignore

---

Workflow 3: Create a New Dashboard

Creating a new dashboard with gcx involves authoring a resource file locally and then pushing it to Grafana.

Step 1: Get an existing dashboard as a template

Pull a similar dashboard to use as a starting point:

gcx resources pull dashboards/existing-uid -p ./templates -o yaml

Or list available dashboards to find a suitable one:

gcx resources get dashboards -o wide

Step 2: Author the resource file

Create a new YAML or JSON file. Set metadata.name to a human-readable name; leave metadata.uid empty (gcx assigns a UID on first push) or set it explicitly to a value you choose.

Minimal dashboard resource structure:

apiVersion: dashboard.grafana.app/v1alpha1
kind: Dashboard
metadata:
  name: my-new-dashboard
  # uid: leave empty for auto-assignment, or set explicitly
spec:
  title: "My New Dashboard"
  tags: []
  panels: []
  # Optional: place in a folder
  # folderUID: <folder-uid>

Step 3: Validate before pushing

# Validate the file against Grafana's API schema
gcx resources validate -p ./my-new-dashboard.yaml

Resolve any validation errors before proceeding.

Step 4: Push the new dashboard

gcx resources push -p ./my-new-dashboard.yaml

gcx assigns a UID and sets grafana.app/managed-by: gcx automatically. Pull the dashboard after pushing to capture the assigned UID:

gcx resources pull dashboards/<assigned-uid>

Step 5: Iterate with the live dev server

For iterative panel authoring, use serve to get instant browser previews on every file save:

gcx dev serve ./dashboards

See the serve command reference in `references/resource-operations.md` for full flag details and the hot-reload workflow.

---

Workflow 4: Validate Dashboard Files

Validate checks local resource files against the Grafana API schema without writing anything to Grafana. Use this in CI/CD pipelines and before pushing to production.

Validate default directory

gcx resources validate

Validate a specific path

gcx resources validate -p ./dashboards
gcx resources validate -p ./resources/dashboards/my-dashboard.yaml

Validate multiple directories

gcx resources validate -p ./dashboards -p ./folders

Validate and output as JSON (CI/CD)

gcx resources validate -o json

Expected output structure (field names, not fabricated values):

{
  "results": [
    {
      "file": "<path>",
      "kind": "Dashboard",
      "name": "<name>",
      "uid": "<uid>",
      "valid": true,
      "errors": []
    }
  ],
  "summary": {
    "total": "<count>",
    "valid": "<count>",
    "invalid": "<count>"
  }
}

A non-zero exit code indicates at least one resource failed validation.

---

Workflow 5: Promote Dashboards Across Environments

Promoting dashboards means pulling them from a source environment (e.g., staging) and pushing them to a target environment (e.g., production). This uses gcx's multi-context support.

Prerequisites: one context per environment

Each environment needs a named context in your gcx configuration. If you have not set up multi-context configuration, use the setup-gcx skill to create contexts for staging and production.

# Verify your contexts
gcx config view

# Example: switch active context
gcx config use-context staging
gcx config use-context production

Option A: use --context flag (no active-context switch)

The --context flag targets a specific context for a single command without changing the active context globally. This is the safest pattern for promotion scripts.

# Step 1: Pull dashboards from staging
gcx resources pull --context staging dashboards folders -p ./promote

# Step 2: Review what was pulled
gcx resources validate -p ./promote

# Step 3: Dry-run push to production
gcx resources push --context production -p ./promote --dry-run

# Step 4: Push to production
gcx resources push --context production -p ./promote

Option B: switch active context with use-context

# Pull from staging
gcx config use-context staging
gcx resources pull dashboards folders -p ./promote

# Push to production
gcx config use-context production
gcx resources push -p ./promote

Folder ordering during promotion

Because the promote directory contains both folders and dashboards, gcx automatically pushes folders before dashboards in the target environment. You do not need to run separate commands for folders and dashboards.

Handling manager metadata during promotion

Dashboards pulled from staging carry grafana.app/managed-by: gcx. When you push them to production, gcx recognizes the annotation and allows the push without --include-managed. If the production environment already has dashboards managed by another tool (UI, Terraform), add --include-managed to take ownership:

gcx resources push --context production -p ./promote --include-managed

Full promotion script pattern

#!/bin/bash
set -e
SOURCE_CTX=staging
TARGET_CTX=production
WORK_DIR=$(mktemp -d)

# Pull from source
gcx resources pull --context "$SOURCE_CTX" dashboards folders -p "$WORK_DIR"

# Validate
gcx resources validate -p "$WORK_DIR"

# Dry run on target
gcx resources push --context "$TARGET_CTX" -p "$WORK_DIR" --dry-run

# Apply
gcx resources push --context "$TARGET_CTX" -p "$WORK_DIR"

---

Workflow 6: Capture Dashboard Snapshots

Render a Grafana dashboard or individual panel to a PNG image using the Grafana Image Renderer. Requires the grafana-image-renderer plugin on the Grafana instance.

If stuck, run gcx dashboards snapshot --help for the full flag

reference, or gcx dashboards --help to see available subcommands.

Step 1: Find the dashboard UID

# List all dashboards to find UIDs
gcx resources get dashboards

# Get a specific dashboard by name substring (use -ojson for programmatic access)
gcx resources get dashboards -ojson | jq '.items[] | {uid: .metadata.name, title: .spec.title}'

Step 2: Discover template variables (if the dashboard uses them)

Most dashboards have template variables (cluster, datasource, job, etc.) that control what data is displayed. To render a meaningful snapshot, you should set these to the values relevant to the user's context.

# Inspect the dashboard's template variables
gcx resources get dashboards/<uid> -ojson | jq '.spec.templating.list[] | {name, type, current: .current.value}'

This shows each variable's name and its current default value. Use --var to override any of these during rendering.

Step 3: Render the snapshot

# Basic: full dashboard, current directory
gcx dashboards snapshot <uid>

# With output directory
gcx dashboards snapshot <uid> --output-dir ./snapshots

# With template variable overrides (match the dashboard's variable names)
gcx dashboards snapshot <uid> --var cluster=prod --var datasource=grafanacloud-prom

# With time range
gcx dashboards snapshot <uid> --since 6h --var cluster=prod
gcx dashboards snapshot <uid> --from now-1h --to now --tz UTC

# Single panel (find panel IDs from the dashboard JSON: .spec.panels[].id)
gcx dashboards snapshot <uid> --panel 42

# Custom dimensions and theme
gcx dashboards snapshot <uid> --width 1280 --height 720 --theme light

# Multiple dashboards concurrently
gcx dashboards snapshot uid-a uid-b uid-c --output-dir ./snapshots

Output

Agent mode (auto-detected): JSON array to stdout with file paths and metadata:

[{"uid": "<uid>", "panel_id": null, "file_path": "/abs/path/<uid>.png", "width": 1920, "height": -1, "theme": "dark", "rendered_at": "<RFC3339>"}]

Human mode: table with columns UID, Panel, File, Size.

Files are named {uid}.png (full dashboard) or {uid}-panel-{panelId}.png (single panel).

Troubleshooting

# If rendering fails with 500 or "plugin not found":
# → The grafana-image-renderer plugin is likely not installed on the Grafana instance

# If the snapshot shows default/wrong variable values:
# → Inspect variables and pass the right ones with --var
gcx resources get dashboards/<uid> -ojson | jq '.spec.templating.list[] | {name, current: .current.value}'

# If the snapshot is cut off or too small:
# → Default height is -1 (full page). Override with --height if needed.
# → For panels, default is 800x600. Override with --width/--height.

# Full flag reference:
gcx dashboards snapshot --help

---

Common Operations

Delete a dashboard

# Delete a specific dashboard
gcx resources delete dashboards/my-uid

# Dry-run before bulk delete
gcx resources delete dashboards/temp-* --dry-run
gcx resources delete dashboards/temp-* -y

Edit a dashboard in-place

Opens the resource in $EDITOR, then pushes the updated version:

gcx resources edit dashboards/my-uid
gcx resources edit dashboards/my-uid -o yaml

List available resource kinds

gcx resources schemas

---

References

• `references/resource-operations.md` —

Full flag reference for all gcx resources subcommands, selector syntax, and serve workflow details.

• `references/resource-model.md` —

Kubernetes-style resource structure, manager metadata behavior, dependency rules (folders before dashboards), push ordering phases, and resource lifecycle (create, read, update, delete).

Grafana Resource Model

This document describes how Grafana resources are structured and how they relate to each other.

Resource Structure

All Grafana resources follow Kubernetes-style conventions:

apiVersion: dashboard.grafana.app/v1alpha1
kind: Dashboard
metadata:
  name: my-dashboard
  namespace: default  # org-id (on-prem) or stack-id (cloud)
  uid: abc123
  annotations:
    grafana.app/managed-by: gcx
    grafana.app/source-file: /path/to/dashboard.yaml
    grafana.app/source-format: yaml
spec:
  # Dashboard specification
  title: "My Dashboard"
  panels: [...]

Key Fields

• apiVersion: Format is {resource}.{group}/{version} (e.g., dashboard.grafana.app/v1alpha1)
• kind: Resource type (Dashboard, Folder, Datasource, etc.)
• metadata.name: Human-readable name
• metadata.uid: Unique identifier (required for updates, auto-generated for creates)
• metadata.namespace: Organization ID (on-prem) or Stack ID (Grafana Cloud)
• metadata.annotations: Metadata about management and source
• spec: Resource-specific configuration

Resource Relationships

Hierarchical Dependencies

Grafana Instance
├── Organizations (on-prem) / Stacks (cloud)
    ├── Folders
    │   └── Dashboards (must reference parent folder)
    ├── Datasources
    ├── Alert Rules
    ├── Contact Points
    └── Notification Policies

Dependency Rules

1. Folders → Dashboards: Dashboards can optionally belong to a folder

• Dashboard spec.folderUID must reference an existing folder UID
• gcx pushes folders before dashboards to ensure dependencies exist
• Dashboards without folderUID go to the "General" folder

2. Datasources → Dashboards: Dashboard panels reference datasources by UID

• Panel datasource.uid must match an existing datasource UID
• Datasources should exist before pushing dashboards that reference them

3. Alert Rules → Datasources: Alert rules query datasources

• Alert rule queries reference datasource UIDs
• Datasources must exist before creating alerts

4. Alert Rules → Folders: Alert rules can be organized in folders

• Similar to dashboards, optional folder relationship

Resource Groups

Grafana organizes resources into API groups:

Core Resources

• dashboard.grafana.app: Dashboards, folders
• datasource.grafana.app: Datasources (generic)
• prometheus.datasource.grafana.app: Prometheus-specific operations
• loki.datasource.grafana.app: Loki-specific operations

Alerting Resources

• alerting.grafana.app: Alert rules, contact points, notification policies
• notifications.grafana.app: Notification templates

Access Control

• iam.grafana.app: Service accounts, API keys (read-only in gcx)
• team.grafana.app: Teams and permissions

Excluded Groups

gcx excludes certain groups from normal operations:

• featuretoggle.grafana.app: Internal feature flags
• iam.grafana.app: Sensitive access control (requires special handling)

Manager Metadata

Resources track which tool manages them:

metadata:
  annotations:
    grafana.app/managed-by: gcx
    grafana.app/source-file: ./resources/dashboards/my-dashboard.yaml
    grafana.app/source-format: yaml

Manager Behavior

• Resources created by gcx: Can be freely modified by gcx
• Resources created by UI/Terraform/other: Protected by default
• Use --include-managed to modify (use with caution)
• Prevents accidental overwrites from different tools

Three-Way Merge (Future)

Currently gcx uses simple upsert logic. Future versions will implement proper three-way merge:

• Track field ownership by manager
• Allow multiple managers to coexist
• Detect and resolve conflicts
• Similar to kubectl apply behavior

Resource Versioning

API Versions

Resources can have multiple API versions:

• v1alpha1: Alpha version, subject to breaking changes
• v1beta1: Beta version, more stable
• v1: Stable version (when available)

gcx uses preferred version by default (typically latest stable version).

Resource Versions (Future)

Currently gcx does not track resourceVersion for optimistic locking. Future versions will:

• Include resourceVersion in metadata
• Detect concurrent modifications
• Retry on conflict with exponential backoff

Discovery System

gcx dynamically discovers available resources using Grafana's API:

# Discover what's available
gcx resources schemas

Discovery process: 1. Calls Grafana's ServerGroupsAndResources API 2. Builds index of available resource types by GVK (Group, Version, Kind) 3. Determines preferred version for each resource type 4. Filters out excluded groups (featuretoggle, iam, etc.) 5. Caches results for subsequent operations

Push Order

When pushing multiple resources, gcx ensures correct order:

1. Phase 1 - Folders: Create folders first 2. Phase 2 - Other Resources: Create dashboards, datasources, etc. 3. Concurrent Operations: Resources within same phase pushed concurrently (default 10 concurrent)

Example:

# This automatically handles ordering
gcx resources push dashboards folders

# Internally:
# 1. Pushes all folders first
# 2. Then pushes dashboards (which may reference folders)

Source Tracking

gcx tracks where resources came from:

metadata:
  annotations:
    grafana.app/source-file: ./resources/dashboards/my-dashboard.yaml
    grafana.app/source-format: yaml

Benefits:

• Round-trip preservation: Pull/push maintains original format
• Error context: Error messages include file path
• Debugging: Know which file caused an issue

Resource Filtering

gcx supports flexible resource selection:

By Kind

gcx resources pull dashboards
gcx resources pull dashboards folders

By UID

gcx resources pull dashboards/my-dashboard-uid
gcx resources pull dashboards/uid1,uid2,uid3

By Version

# Preferred version (default)
gcx resources pull dashboards

# All versions
gcx resources pull dashboards --all-versions

# Specific version
gcx resources pull dashboards.v1alpha1.dashboard.grafana.app

Memory Considerations

gcx loads all resources into memory during operations:

• Typical usage: ~1MB per 100 dashboards
• Practical limit: ~10,000 resources before memory pressure
• Mitigation: Use selective pulling (specific resource types or UIDs)

Future versions may add streaming support for very large deployments.

Resource Lifecycle

Create

# Create new resource from file
gcx resources push -p ./my-dashboard.yaml

• UID auto-generated if not specified
• Manager metadata added automatically
• Folders created before dashboards

Read

# Get resource from Grafana
gcx resources pull dashboards/my-dashboard-uid

• Fetches current state from Grafana
• Includes all metadata
• Format preserved if previously pulled

Update

# Modify and push back
gcx resources edit dashboards/my-dashboard-uid
gcx resources push

• Requires existing UID in metadata
• Only gcx-managed resources (unless --include-managed)
• Server-managed fields stripped before update

Delete

# Remove from Grafana
gcx resources delete dashboards/my-dashboard-uid

• Permanent deletion from Grafana
• Does not delete local files
• No dependency checking (dashboards not deleted when folder deleted)

Best Practices

1. Use UIDs consistently: Always reference resources by UID, not name 2. Respect manager boundaries: Don't mix gcx with UI/Terraform for same resources 3. Folders before dashboards: Always push folders before dashboards that reference them 4. Selective pulling: Pull only what you need to reduce memory usage 5. Version control: Commit resources to git for history and collaboration 6. Dry-run first: Use --dry-run before production pushes 7. Context per environment: Create separate context for dev/staging/prod 8. Source format: Choose JSON or YAML and stick with it for consistency

Resource Operations Reference

<!-- Flag names and defaults verified against gcx source as of T1 audit (2026-03-07). Source files: cmd/gcx/resources/get.go, push.go, pull.go, delete.go, edit.go, validate.go, serve.go. Do not update examples without re-auditing the CLI. -->

This file documents the full flag set and usage patterns for each gcx resources subcommand, the selector syntax, and the serve live development workflow.

---

Selector Syntax

Selectors are positional arguments passed to commands that accept [RESOURCE_SELECTOR].... They control which resources the command operates on.

Kind Selector

Targets all resources of a given kind. The kind name is the plural resource name as reported by gcx resources schemas.

gcx resources get dashboards
gcx resources pull dashboards
gcx resources delete dashboards --force

UID Selector

Targets a single resource by its UID. Format: <kind>/<uid>.

gcx resources get dashboards/my-dashboard-uid
gcx resources edit dashboards/my-dashboard-uid
gcx resources delete dashboards/my-dashboard-uid

Glob Pattern

Targets resources whose UID matches a glob pattern. Use * for any substring within a UID segment.

gcx resources get dashboards/my-*
gcx resources pull dashboards/prod-*
gcx resources delete dashboards/temp-* --dry-run

Multi-Selector

Pass multiple selectors as separate positional arguments to target more than one kind or UID set in a single command. Selectors are evaluated independently and their results are merged.

# All dashboards and all folders
gcx resources get dashboards folders

# Two specific dashboards plus all folders
gcx resources get dashboards/uid-a dashboards/uid-b folders

---

gcx resources get

Fetch and display resources from Grafana.

Flags

Usage

# List all dashboards as a table
gcx resources get dashboards

# Get a specific dashboard in YAML
gcx resources get dashboards/my-uid -o yaml

# Get all folders in JSON (useful for scripting)
gcx resources get folders -o json

# Get dashboards and folders together, wide output
gcx resources get dashboards folders -o wide

# Get dashboards matching a glob, ignore per-resource errors
gcx resources get dashboards/prod-* --on-error ignore

---

gcx resources push

Write local resource files to Grafana. Handles folder/dashboard topological ordering automatically: folders are pushed level-by-level before dashboards when both are present.

Flags

Usage

# Push everything under ./resources (default path)
gcx resources push

# Push from a specific directory
gcx resources push -p ./dashboards

# Push from multiple directories
gcx resources push -p ./dashboards -p ./folders

# Dry run: show what would change without writing
gcx resources push --dry-run

# Push and override resources managed by other tools
gcx resources push --include-managed

# Push with abort-on-first-error and limited concurrency
gcx resources push --on-error abort --max-concurrent 5

Manager Metadata Behavior

When gcx pushes a resource it sets the annotation:

annotations:
  grafana.app/managed-by: gcx

Resources that carry a different grafana.app/managed-by value (set by Terraform, the Grafana UI, or another tool) are protected by default. gcx will refuse to push over them unless --include-managed is passed. This prevents accidental overwrites of resources managed by other systems.

---

gcx resources pull

Download resources from Grafana and write them to local files.

Flags

Usage

# Pull all dashboards into ./resources (JSON format)
gcx resources pull dashboards

# Pull to a custom directory in YAML format
gcx resources pull dashboards -p ./my-dashboards -o yaml

# Pull dashboards and folders together
gcx resources pull dashboards folders

# Pull a specific dashboard
gcx resources pull dashboards/my-uid

# Pull resources regardless of who manages them
gcx resources pull dashboards --include-managed

---

gcx resources delete

Delete resources from Grafana.

Flags

Usage

# Delete a specific dashboard (no --force needed for UID selectors)
gcx resources delete dashboards/my-uid

# Delete all dashboards matching a glob — dry run first
gcx resources delete dashboards/temp-* --dry-run
gcx resources delete dashboards/temp-* -y

# Delete all dashboards of a kind (requires --force as a safety gate)
gcx resources delete dashboards --force --dry-run
gcx resources delete dashboards --force -y

# Delete resources from local files
gcx resources delete -p ./old-dashboards -y

Safety: Kind-only selectors require --force to prevent accidental mass-deletion.

Always use --dry-run first when deleting by glob or kind.

---

gcx resources edit

Open a single resource in $EDITOR for in-place editing, then push the updated resource back to Grafana.

Flags

Usage

# Edit a dashboard in the default format (JSON)
gcx resources edit dashboards/my-uid

# Edit using YAML in the editor
gcx resources edit dashboards/my-uid -o yaml

Edit accepts exactly one positional selector. The resource is fetched, opened in $EDITOR, and pushed back on save. Exiting without changes is a no-op.

---

gcx resources validate

Validate local resource files against the Grafana API schema without writing anything.

Flags

Usage

# Validate everything under ./resources
gcx resources validate

# Validate a specific directory
gcx resources validate -p ./dashboards

# Validate and output results as JSON (useful in CI)
gcx resources validate -o json

# Validate from multiple directories
gcx resources validate -p ./dashboards -p ./folders

---

gcx dev serve

Start a live development server that watches local resource files and hot-reloads them into Grafana as they change. The browser refreshes automatically when a resource is updated.

Flags

Positional arguments are resource directories to serve.

Live Dev Server Workflow

The serve command creates a tight edit-preview loop for dashboard development:

1. Start the server — gcx watches the resource directories and listens for browser connections. 2. Edit a resource file — change the JSON/YAML on disk (manually or via a script). 3. Hot reload — gcx detects the file change, pushes the updated resource to Grafana, and signals connected browsers to refresh the dashboard panel view. 4. Browser preview — open http://localhost:8080 (or the configured address/port) to see the live Grafana panel. The preview refreshes automatically on each save.

Developer          gcx serve       Grafana API        Browser
    |                     |                    |                 |
    |-- edit file ------->|                    |                 |
    |                     |-- push resource -->|                 |
    |                     |<-- 200 OK ---------                 |
    |                     |-- ws: reload signal --------------->|
    |                     |                    |<-- GET panel ---|

Usage

# Serve resources from the default directory (./resources)
gcx dev serve .

# Serve a specific directory
gcx dev serve ./dashboards

# Serve with a custom port, watch additional path
gcx dev serve ./dashboards --port 9090 -w ./shared-panels

# Serve a script-generated resource (re-runs script on each file change)
gcx dev serve . --script ./generate-dashboard.sh --script-format json

# Serve without watching (push once and exit)
gcx dev serve ./dashboards --no-watch

---

--on-error Policy Reference

All commands that process multiple resources accept --on-error to control behavior when an individual resource operation fails.

Default: fail — processes all resources and reports failures at the end without stopping the batch.

Use ignore in CI pipelines where partial success is acceptable. Use abort when subsequent operations depend on all prior operations succeeding (e.g., folder creation before dashboard push in a multi-step script).