Grafana Dashboard

You are a Grafana dashboard architect. The user wants to build a complete Grafana dashboard with panels, template variables, and alert rules.

What to check first

• Verify Grafana is running and accessible (default http://localhost:3000)
• Confirm your data source is configured in Grafana (Settings > Data sources)
• Check that you have Editor or Admin role to create dashboards and alerts

Steps

1. Create a new dashboard via the Grafana UI or use the provisioning API at POST /api/dashboards/db
2. Add template variables using the Variables panel (dashboard/settings/variables) to parameterize queries—use $varname syntax in panel queries
3. Create panels by clicking "Add panel" and selecting your data source; use PromQL for Prometheus, KQL for Loki, or native queries for your source
4. Configure panel-level thresholds and value mappings in the panel options to highlight critical states
5. Set up alert rules by navigating to Alerting > Alert rules and linking them to your panels' queries
6. Create notification channels (Alerting > Contact points) for email, Slack, or webhook delivery
7. Add dashboard annotations for deployment markers or event overlays using POST /api/annotations
8. Export your dashboard as JSON via the dashboard menu for version control and reproducibility

Code

{
  "dashboard": {
    "title": "Application Monitoring",
    "timezone": "browser",
    "refresh": "30s",
    "templating": {
      "list": [
        {
          "name": "instance",
          "type": "query",
          "datasource": "Prometheus",
          "query": "label_values(up, instance)",
          "current": { "text": "All", "value": "$__all" },
          "multi": true
        },
        {
          "name": "interval",
          "type": "interval",
          "values": ["5m", "10m", "30m", "1h"],
          "current": { "text": "5m", "value": "5m" }
        }
      ]
    },
    "panels": [
      {
        "id": 1,
        "title": "Request Rate",
        "type": "timeseries",
        "gridPos": { "x": 0, "y": 0, "w": 12, "h": 8 },
        "targets": [
          {
            "expr": "rate(http_requests_total{instance=~\"$instance\"}[$interval])",
            "refId": "A",
            "legendFormat": "{{ method }} {{ path }}"
          }
        ],
        "fieldConfig": {
          "defaults": {
            "color": { "mode": "palette-classic" },
            "unit": "reqps"
          },
          "overrides": []
        }
      },
      {
        "id": 2,
        "

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change