Building Dashboards in Azure Monitor

Two tools, two purposes

Azure offers two visualization tools within the Monitor ecosystem, and they serve different audiences:

• Azure dashboards — Portal-wide pinboard. Pin metric charts, log query results, resource status, and external links. Good for an always-visible operations TV dashboard or a personal resource overview. Simple to create, limited in interactivity.
• Azure Monitor workbooks — Rich interactive reports. Support multiple sections, tabbed layouts, parameter dropdowns, conditional rendering, and combinations of KQL queries and metric charts on the same page. Good for SLA reports, incident post-mortems, capacity planning documents, and team-facing analysis tools.

In practice, most mature monitoring setups use both: a dashboard for the main operations screen that shows “is everything healthy right now?”, and workbooks for detailed investigation and reporting.

Creating an operations dashboard

You build Azure dashboards by pinning tiles from elsewhere in the portal, or by uploading a JSON definition. The JSON approach is better for teams because it can be version-controlled and deployed consistently across environments.

# List existing dashboards in a resource group
az portal dashboard list \
  --resource-group myRG \
  --output table

# Create a dashboard from a JSON template
az portal dashboard create \
  --resource-group myRG \
  --name "ProductionOperations" \
  --input-path dashboard.json \
  --location eastus

A minimal dashboard JSON structure that places a metric chart tile:

{
  "lenses": {
    "0": {
      "order": 0,
      "parts": {
        "0": {
          "position": { "x": 0, "y": 0, "colSpan": 6, "rowSpan": 4 },
          "metadata": {
            "type": "Extension/Microsoft_Azure_MonitoringMetrics/PartType/MetricsChartPart",
            "inputs": [{
              "name": "options",
              "value": {
                "chart": {
                  "metrics": [{
                    "resourceMetadata": {
                      "id": "/subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Web/sites/myapp"
                    },
                    "name": "Http5xx",
                    "aggregationType": 1,
                    "namespace": "microsoft.web/sites"
                  }],
                  "title": "HTTP 5xx Errors",
                  "timespan": { "relative": { "duration": 3600000 } }
                }
              }
            }]
          }
        }
      }
    }
  },
  "metadata": {
    "model": { "timeRange": { "value": { "relative": { "duration": 24, "timeUnit": 1 } } } }
  }
}

Azure Monitor workbooks

Workbooks live in Azure Monitor → Workbooks. They are composed of sections called “steps”, each of which can be a text block, a KQL query visualization, a metrics chart, or a parameter control. Steps can reference parameter values, making the workbook interactive — for example, a dropdown that lets users select a time range or an environment.

A workbook for application health monitoring might include:

1. A parameter row: time range picker, environment selector (production/staging)
2. A metrics section: request rate, error rate, response time as time charts
3. A log section: top 10 slowest requests, exception summary
4. A dependency health section: average latency and failure rate per downstream service
5. A user impact section: users affected by errors, affected user count trend

KQL queries that power useful workbook tiles

These queries are designed as workbook tiles — each producing a clean visualization for a specific health concern.

// Tile 1: Request rate and error rate side by side (for a grid layout)
AppRequests
| where TimeGenerated > {TimeRange:start} and TimeGenerated < {TimeRange:end}
| summarize
    RequestRate = count(),
    ErrorRate = countif(Success == false),
    AvgResponseMs = avg(DurationMs)
    by bin(TimeGenerated, 5m)
| render timechart

// Tile 2: Service dependency health table
AppDependencies
| where TimeGenerated > {TimeRange:start} and TimeGenerated < {TimeRange:end}
| summarize
    CallCount = count(),
    FailureCount = countif(Success == false),
    P95LatencyMs = percentile(DurationMs, 95)
    by Target, DependencyType
| extend FailureRate = round(100.0 * FailureCount / CallCount, 1)
| order by FailureRate desc, P95LatencyMs desc

// Tile 3: Top exceptions in the time window
AppExceptions
| where TimeGenerated > {TimeRange:start} and TimeGenerated < {TimeRange:end}
| summarize OccurrenceCount = count() by ExceptionType, OuterMessage
| top 10 by OccurrenceCount

// Tile 4: SLA compliance — what percentage of requests completed under 500ms?
AppRequests
| where TimeGenerated > {TimeRange:start} and TimeGenerated < {TimeRange:end}
| summarize
    Total = count(),
    WithinSLA = countif(DurationMs < 500)
| extend SLAPercent = round(100.0 * WithinSLA / Total, 2)
| project SLAPercent, WithinSLA, Total

Built-in workbook templates

Azure Monitor ships with dozens of pre-built workbook templates that cover common monitoring scenarios. You find them in Azure Monitor → Workbooks → the gallery view. Notable templates include:

Dashboard design principles

A dashboard that tries to show everything shows nothing useful. Design dashboards with a specific audience and context in mind.

• One question per dashboard. An operations dashboard answers “is the system healthy right now?” A capacity dashboard answers “are we approaching limits?” A business dashboard answers “how is the application being used?” Do not try to answer all three on one screen.
• Red-amber-green tiles first. Put the most critical status indicators at the top-left where attention goes first. Error rates, availability percentages, and alert summaries should be immediately visible without scrolling.
• Use relative time ranges. Dashboards pinned with a fixed time range (e.g., “2026-03-01 to 2026-03-31”) become stale immediately. Use relative ranges (last 4 hours, last 24 hours) that are always current.
• Include context for anomalies. A spike in the error rate chart is more useful when the dashboard also shows deployment markers or linked workbook buttons for drill-down investigation.