> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Customizing Dashboards
> Build custom metric dashboards with panel types, filters, groupings, multiple datasets, and export options for incident analytics.
Rootly's default dashboards get you started, but the interesting questions come from your own combinations of collections, filters, aggregations, and groupings. This page covers how to build custom panels and shape them into dashboards that answer the questions your team actually asks.
Start with a question, not a chart type. Pick the collection, filters, and metric that answer the question — then choose how to visualize it.
***
## How metric panels work
A **panel** is the building block of every dashboard. Panels can be visual (charts), tabular (tables), or KPI-style (aggregate values). Every panel is defined by a combination of:
A **panel** is the building block of every dashboard. Every panel combines the same seven pieces:
* **Display type** — how the data appears (line, column, table, aggregate value, etc.)
* **Collection** — which records the panel pulls from (Incidents, Alerts, Retrospectives, Action Items, Users)
* **Filters** — which subset of the collection is included
* **Aggregation operation** — how results are calculated (Count, Average, Sum)
* **Metric key** — what you're measuring (`resolution_time`, `hours_worked`, etc.)
* **Group By** — how results are segmented across categories
* **One or more datasets** — combinations of the above for comparisons and multi-series charts
Data selection (collection + filters), calculation (operation + key), and display (panel type + grouping) are separate concerns. That's what makes panels composable — you can reuse the same dataset across visualizations or refine filters without redesigning the panel.
***
## Panel types
Rootly supports the following panel types:
Rootly supports these panel types:
* **Line Chart** — trend over time
* **Line Stepped Chart** — trend with discrete transitions
* **Column Chart** — volume comparison across categories
* **Stacked Column Chart** — composition within totals
* **Monitoring Chart** — time-series data optimized for monitoring-style visualization
* **Pie Chart** — proportional distribution
* **Table** — raw records for operational drill-down
* **Aggregate Value** — a single formatted number for KPI displays
Monitoring charts use the same configuration model as other panels (datasets, filters, group-by, export) but render optimized for high-frequency time-series data.
### Table Panels
Table panels display raw records rather than aggregated metrics. They support selecting visible columns, including custom fields and incident roles as columns, and exporting the full dataset.
Tables display up to **100 rows** in the UI for performance. Exports can include the full dataset.
### Aggregate Value Panels
Aggregate panels display a single formatted number — ideal for KPI dashboards, executive summaries, and top-of-dashboard headline metrics. Examples: total incidents, average time-to-resolve, total hours worked.
Because aggregate panels show a single value, use them sparingly at the top of a dashboard with deeper analytical panels below.
***
## Collections and access
Panels pull from one of five collections:
* **Alerts**
* **Incidents**
* **Retrospectives**
* **Action Items**
* **Users**
Which collections are available depends on your product access (seat type).
On-Call seats typically see **Alerts** only. Incident Response seats see **Incidents**, **Retrospectives**, **Action Items**, and **Users** in addition.
***
## Add a metric panel
To add a panel:
1. Go to **Metrics** and open the dashboard you want to edit
2. Click **+ Add Panel**
3. Configure the panel (type, collection, filters, operation, key, etc.)
4. Click **Create**
***
## Edit, Move, and Resize Panels
To edit a panel, hover it → click **⋯** → **Settings**, update, click **Update**. Rootly validates configuration on save and shows targeted errors for invalid keys, operations, or filter conditions.
## Edit panels
To edit a panel:
1. Open the dashboard in **Metrics**
2. Hover over the panel
3. Click **⋯**
4. Select **Settings**
5. Update configuration and click **Update**
**Validation happens on save**
Rootly validates your configuration before saving. If you select an invalid key, operation, or filter condition, you’ll see a targeted error message so you can correct it immediately.
***
## Move and resize panels
Filtering has two layers: **dashboard-level filters** (your personal view preferences) and **panel-level filters** (persistent and shared with everyone who views the panel).
### Dashboard-Level Filters
Panels are stored as grid coordinates (not pixels), meaning layouts stay consistent across screen sizes.
**Grid defaults**
Panels default to a grid size of **6 columns wide × 3 rows tall**, with a minimum height enforced for readability.
***
## Filters
Filtering determines *what counts*.
Without intentional filtering, dashboards become noise generators. With thoughtful filtering, they become precision tools.
In Rootly, filtering operates on two layers: global view preferences (personal and temporary) and panel-level filters (persistent and shared). Understanding the difference is critical for designing dashboards that are both flexible and consistent.
* **Dashboard-level filters** (your personal view preferences)
* **Panel-level filters** (saved as part of the panel configuration)
These two layers combine to determine what any panel actually shows.
***
## Dashboard-level filters (view preferences)
Dashboard-level filters apply to **all panels** and are saved **per user**:
* Date range (for example, Last 30 Days)
* Period (day / week / month / quarter / year)
* Team filters
* Service filters
Changing your dashboard filters does not edit the dashboard or affect what other viewers see. If you want a change to stick for everyone, edit the panel's own filters.
### Panel-Level Filters
Panel-level filters are stored with the panel and define exactly which records enter its dataset for every viewer. Supported operators depend on the field type:
* `=` (equals) / `!=` (not equals)
* `>=` / `<=`
* `exists` / `not_exists`
* `contains` / `not_contains`
* `assigned` / `unassigned` (incident roles only)
Incident roles support `assigned` and `unassigned` — useful for panels like *Incidents Missing an Incident Commander* or *SEV0s Where Comms Lead Is Unassigned*.
### Filter Groups (AND / OR Logic)
Filters can be grouped with AND / OR logic for expressive conditions:
* (SEV0 OR SEV1) AND (Environment = Production)
* (Service Contains Payments) OR (Functionality Contains Checkout)
AND groups require all rules to match. OR groups match if any rule matches.
## Group By
Group By segments results within a panel, turning a single metric into a comparison. Use it when the question is *"how does this split across…"*:
* Which teams generate the most incidents?
* Which services have the longest time-to-resolve?
* How do SEV0 counts differ by environment?
Group By creates multiple series for line and column charts, segments pie charts, and supports grouping by custom fields and incident roles.
Group By is often the difference between a dashboard that reports and a dashboard that informs. If a metric is actionable, it usually has an owner — grouping by team, service, or type makes accountability visible without extra panels.
***
## Multiple datasets (comparisons)
Chart panels can include multiple datasets. Each dataset can have its own collection, filters, operation, key, and series name. Use multiple datasets for side-by-side comparisons in a single panel:
* SEV0 count vs SEV1 count over time
* Time to mitigate vs time to resolve
* Incidents from Team A vs Team B
Multiple datasets keep executive dashboards compact — you can compare related signals in one panel instead of stacking separate panels vertically.
***
## Cumulative charts
Certain chart types support **cumulative mode**, which displays running totals over time.
Supported chart types:
* Line chart
* Line stepped chart
* Column chart
* Stacked column chart
Cumulative mode is useful for:
* “Incidents year-to-date”
* “Total alerts this quarter”
* “Action items created this month”
***
## Table panels
Table panels display **raw records** rather than aggregated metrics.
They are useful when you want a dashboard that supports both:
* macro analysis (charts and KPIs), and
* direct operational drill-down (lists of incidents, alerts, or action items)
Line, line-stepped, column, and stacked-column charts support **cumulative mode**, which displays running totals over time. Useful for "year-to-date incidents", "total alerts this quarter", "action items created this month".
***
## Aggregate value panels
Aggregate panels display a **single formatted number**—ideal for KPI dashboards.
Examples:
* Total incidents (count)
* Average time-to-resolve (average)
* Total hours worked until mitigated (sum)
These panels are best for:
* Exec summaries
* Weekly reliability reviews
* “Top row” dashboard metrics
Because aggregate panels show a single value, they should be used intentionally and sparingly. They are most effective when placed at the top of a dashboard as summary indicators — supported by deeper analytical panels below.
Think of aggregate panels as headlines. The charts beneath them are the supporting evidence.
***
## Operations and keys
## Operations
Operations vary depending on the collection:
* **Count** — available for all collections
* **Average** — commonly available for Alerts and Incidents
* **Sum** — available for Alerts, Incidents, and Users (depends on the metric key)
If an operation doesn't appear for a collection, there isn't a valid numeric metric to average or sum across those records.
**Keys** are collection-specific and depend on the operation you select.
### Incidents
* **Count:** `results`
* **Average / Sum:** `triage_time`, `detection_time`, `acknowledge_time`, `mitigation_time`, `resolution_time`, `cancellation_time`, `closed_time`
### Alerts
* **Count:** `results`
* **Average:** `acknowledge_time`, `resolution_time`, `time_between_failure`
* **Sum:** `acknowledge_time`, `resolve_time`
### Users
* **Count:** `results`
* **Sum:** `hours_worked_until_triaged`, `hours_worked_until_mitigated`, `hours_worked_until_resolved`
***
## Time-based behavior
Dashboards apply time filtering automatically based on the selected date range.
Depending on the collection, Rootly uses different timestamps to scope records (for example, incidents and alerts use their `started_at` timestamps). This ensures charts remain consistent when comparing across dashboards and periods.
Time scoping is applied consistently across collections to ensure analytical integrity. This means comparisons between alerts, incidents, and retros remain aligned when viewing the same date range.
If data appears incomplete or unexpectedly low, the first place to check is always your dashboard-level date range.
Panels inherit the dashboard's date range and period grouping. Different collections scope on different timestamps (incidents and alerts scope on `started_at`, for example) so cross-collection comparisons stay aligned.
If results look incomplete or unexpectedly low, check the dashboard-level date range first.
***
## Exporting dashboards and panels
### Export a Dashboard
Open the dashboard → **⋯** → **Download PDF**. The full dashboard renders as a PDF suitable for meeting decks and reliability reports.
### Export a Panel
Hover the panel → **⋯** → choose the format:
| Format | Available For |
| :- | :- |
| **PDF** | All panel types |
| **CSV** | All panel types |
| **JSON** | All panel types |
| **PNG / JPG** | Chart panels only |
Table exports include the full dataset — the UI-side 100-row cap does not apply to exports.
***
## Duplicate a panel
Hover a panel → **⋯** → **Duplicate**. Duplicated panels copy every configuration (filters, keys, operations, display type) and land at a default grid position with a `Copy of {original title}` name. Reposition as needed.
***
## Full screen view
Full screen mode is ideal for TVs or wallboards.
Full-screen mode is optimized for TVs and wallboards. Open a dashboard, click the full-screen icon (top-right), and press **ESC** or the icon to exit. Full-screen hides sidebar navigation, maximizes panel readability, and reformats spacing for large displays.
***
## Performance, caching, and limits
Panel data is cached, typically for \~15 minutes. If you recently changed incident data, allow 15–20 minutes for updates to reflect — especially with auto-refresh enabled. Caching keeps dashboards responsive on large datasets and is not adjustable per panel.
Other constraints:
* Panel queries are limited to **10,000 records** by default (higher limits available for Enterprise customers on request).
* Panel titles have a length cap to keep dashboards scannable.
* Table panels cap visible rows in the UI for performance; exports include full datasets.
***
## Best Practices
* **Tie dashboards to a recurring cadence** — weekly reliability reviews, monthly execs, program retrospectives, on-call readiness. Dashboards that aren't tied to a workflow go stale.
* **Prefer fewer, stronger panels.** 6–10 focused panels beat 25 competing for attention. Duplicate and specialize dashboards instead of overloading one.
* **Use Group By as your default depth tool.** Grouping metrics by team, service, or incident type makes accountability visible without needing extra dashboards.
* **Start with the question.** A good panel begins with what you want to know. Pick the collection, filters, and metric that answer that question — the chart type is the last step, not the first.
* **Use tables for drill-down, aggregate values for headlines.** Charts sit between them for trend and comparison.
***
## Troubleshooting
Three things to check, in order: the dashboard-level date range (data outside the range won't appear), the panel-level filters (an over-narrow filter can zero out the panel), and the collection (an Alerts panel won't show Incident data). If all three look right, wait \~15 minutes for the cache to refresh, then reload.
Panel results are cached for \~15 minutes to keep dashboards responsive. Configuration changes save immediately, but the underlying data may take 15–20 minutes to reflect, especially with auto-refresh on. Force a refresh by editing and re-saving the panel, or wait for the cache window to expire.
A `None` group appears when some records don't have a value for the grouped field (incidents with no service assigned, for example). Remove it in two steps:
1. **Filter out the records.** Add a panel filter on the same field you group by, operator **Exists**. Filters apply before grouping, so records missing the value drop out and the `None` group empties. Use **Not Exists** to see only the missing-value records.
2. **Hide the empty group from the legend.** Turn off **Include Groups Without Values** on the panel.
When grouping by an incident role, use the role-specific operators — filter the role as `assigned` to drop unassigned incidents, or `unassigned` to see only those. Works on pie, column, and line charts.
PNG and JPG exports are chart-only. Export tables as **PDF**, **CSV**, or **JSON** instead — all three preserve the full row set and support drill-down analysis.
Operations are gated by whether the collection has a valid numeric metric for that calculation. Users doesn't support Average — there's no per-user numeric metric to average across. If a specific operation is missing that you expect, double-check the collection choice.
Panels support filtering and grouping by custom fields, but a custom field must be enabled for the relevant collection. Under **Configuration → Custom Fields**, confirm the field is enabled for Incidents (or Alerts, etc.) that the panel pulls from.
***
## Frequently Asked Questions
Collections are seat-based. On-Call seats typically see **Alerts** only; Incident Response seats see **Incidents**, **Retrospectives**, **Action Items**, and **Users** in addition.
Dashboard filters are personal view preferences (date range, period, team, service) that apply across all panels without changing the dashboard for other users. Panel filters are stored inside the panel configuration and define the dataset for everyone who views it.
Yes. Panels support filtering and grouping by custom fields, and custom fields can also appear as columns on tables for drill-down workflows.
Panel results are cached for \~15 minutes. Changes to underlying data may take that long to appear, especially with auto-refresh enabled.
Yes. A chart panel can include multiple datasets, each with its own collection, filters, operation, and key. Use this to compare, for example, incidents against alerts on the same time axis.
Mark the dashboard as **Public** in its Sharing settings. This exposes it at a `/public/dashboards/…` URL that renders read-only. Public dashboards use a boolean visibility flag, not per-viewer tokens, so anyone with the URL can view. See [Managing Dashboards → Sharing and Permissions](/metrics/managing-dashboards#sharing-and-permissions).
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.