What is an Amazon CloudWatch dashboard actually made of, what kinds of widget can it hold, and why does putting a metric on a CloudWatch dashboard not mean anyone will be told when it moves?
answer
- saved drawing, not a watcher
- JSON body of widgets
- region and stat live per widget
- nobody is paged by a graph
basics
~20 sA CloudWatch dashboard is a JSON document of widgets — metric graphs, log tables, alarm-status tiles, text — and each widget carries its own region, statistic and period. Dashboards only draw data; notification comes from CloudWatch alarms, never from a dashboard.
solid answer
~50 sA CloudWatch dashboard is stored as a JSON body — a `widgets` array written by the `PutDashboard` API, which is what the console editor produces when you drag things around. Each widget has a `type` (`metric`, `log`, `alarm`, `text`, `custom`), a size and position on a 24-column grid, and a `properties` object holding the metrics it graphs, the `view` (time series, single value, gauge, bar, pie, table), the `stat`, the `period` and — importantly — a `region`. Because region is per widget, one dashboard can show several regions side by side. The thing candidates get wrong is treating a dashboard as monitoring: a dashboard is pull-based and only renders while someone is looking at it. Nothing on it evaluates a threshold or sends a notification. That is a CloudWatch alarm's job; an `alarm` widget on the dashboard merely displays the state an alarm already computed.
go deeper
Be able to say that a dashboard is a saved set of widgets over existing CloudWatch data, name a few widget types, and state plainly that alarms notify while dashboards only display.
Explain the dashboard body as JSON written by PutDashboard, what lives in a widget's properties — metrics, view, stat, period, region — and why region being per widget makes multi-region panes possible.
Show the operational instinct: alarms decide when a human is woken, dashboards are what that human opens next. Call out log widgets as the usual cause of a slow, expensive dashboard.
Own the estate-level view — dashboards as versioned code, a consistent layout teams can navigate under pressure, and a clear split between what pages someone and what merely informs.
## What a dashboard actually is A CloudWatch dashboard is not a stateful monitoring object. It is a **saved JSON document** describing how to draw data that CloudWatch already holds. The console's drag-and-drop editor is a front end over one API call, `PutDashboard`, which takes a dashboard name and a `DashboardBody` string. `GetDashboard` gives you the same JSON back, which is why dashboards are easy to keep in source control and to template across environments. The body's top-level key is `widgets`, an array. Every widget has: - `type` — the widget kind. - `x`, `y`, `width`, `height` — placement on a grid that is **24 columns wide**; height is in grid rows. - `properties` — everything type-specific. ```json { "widgets": [ { "type": "metric", "x": 0, "y": 0, "width": 12, "height": 6, "properties": { "region": "eu-west-1", "view": "timeSeries", "stat": "p99", "period": 60, "metrics": [ ["AWS/ApplicationELB", "TargetResponseTime", "LoadBalancer", "app/prod-alb/abc123"] ] } } ] } ``` ## The widget types - **`metric`** — the workhorse. Its `metrics` array lists `[namespace, metricName, dimName, dimValue, {options}]` tuples, and entries may also be **metric math** or **search expressions** rather than literal metrics. `view` selects the rendering: `timeSeries`, `singleValue`, `gauge`, `bar`, `pie`, `table`. - **`log`** — runs a CloudWatch Logs Insights query and renders the result set. It executes when the dashboard loads, so it costs money per view and is slower than a metric widget. - **`alarm`** — shows the current state of one or more alarms, or an alarm-status grid. It reflects state; it does not create it. - **`text`** — Markdown. Underrated: this is where the runbook link and "what to do when this graph is red" belong. - **`custom`** — invokes a Lambda function that returns HTML or JSON, for data CloudWatch does not natively hold. ## Region and account live on the widget Each `metric` widget's `properties.region` decides which region's metrics are fetched, independently of where the dashboard resource itself was created. That single field is what makes a genuinely multi-region dashboard possible without duplicating anything. Widgets can likewise be pointed at another AWS account once cross-account observability is set up, so one pane can span an estate. ## Statistic and period are display choices `stat` and `period` on the widget are how the data is *rolled up for this graph* — `Sum` at a 60-second period tells a different story from `Average` at 300 seconds over exactly the same underlying metric. Two widgets can disagree visually while both being correct. Always read the statistic and period before concluding anything from a CloudWatch graph. ## Why a dashboard is not monitoring This is the point interviewers are probing. A dashboard: - is **pull-based** — the queries run when a browser opens it, and never otherwise; - **evaluates nothing** — no threshold, no state machine, no notification target; - **wakes nobody** — there is no SNS topic anywhere in its definition. Detection and notification come from CloudWatch alarms, which evaluate on their own schedule whether anyone is watching. The healthy pattern is: alarms decide when a human is needed, dashboards are what that human opens once they have been paged. A team that only builds dashboards has built a wall of graphs that reliably shows an outage to nobody at 3 a.m. ## Practical notes - Dashboards are cheap and code-friendly; treat the JSON as the source of truth and let the console be an editor, not a database. - `GetMetricWidgetImage` renders a single metric widget to a PNG server-side, which is how graphs get attached to incident tickets or chat messages without a login. - A `log` widget with a wide time range is the usual reason a dashboard is slow and unexpectedly expensive to open, because Logs Insights bills by data scanned.
- A colleague wants a dashboard that turns red and emails the team when latency is high. What do you tell them?The dashboard cannot do that. Create a CloudWatch alarm on the latency metric with an SNS action for the notification, then add an `alarm` widget to the dashboard so the same state is visible when someone opens it. The alarm does the evaluating and paging; the widget just mirrors it.
- Two widgets graph the same metric but look completely different. What do you check first?The `stat` and `period` on each widget. `Sum` over 60 seconds and `Average` over 5 minutes render the same underlying data as very different shapes, and a longer period also hides short spikes through aggregation. Check the region property too — the widgets may not be looking at the same account or region at all.
- Why would you keep a dashboard's JSON in a repository rather than editing it in the console?Because the JSON *is* the dashboard — `PutDashboard` takes the whole body, so a file in git is a faithful, reviewable, diffable definition. It lets you template the same layout across environments, restore a dashboard someone deleted, and see who changed a threshold or a metric and when.
saying these in an interview costs you the question
- Thinking a dashboard notifies you when a graph spikes
- Believing a dashboard is limited to a single region
- Assuming a dashboard runs continuously in the background
- Confusing an alarm widget with the alarm itself
- Reading a CloudWatch graph without checking its statistic and period