Customizing Dashboards

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.

---

​

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

​

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.

​

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).

---

​

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

---

​

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.

---

​

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

​

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)

​

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.

---

​

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

---

​

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.

---

​

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:

---

​

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

---

​

Frequently Asked Questions