# Multi-page dashboard > One page can't hold it and the sections have different audiences. - Canonical: https://patterns.konigi.com/dashboards/multi-page-dashboard - Group: Screenspace - Level: context - Status: published - Updated: September 10, 2026 - Also called: tabs, sub-dashboards, dashboard set --- ## Problem The dashboard has outgrown its screen and collapsing sections is no longer enough. What is left is not one long page but several genuinely different pages that happen to share a subject. ## Solution Split into named pages, linked as a set, sharing the state that should be shared. Each page answers a different question about the same thing. The distinction from a hierarchy is worth being firm about, because conflating the two produces navigation nobody can hold. **Overview then detail** is vertical: each level is the same subject narrowed. **Multi-page** is horizontal: the pages are peers, at the same scope, differing in what they show rather than in how much. Traffic, Errors, Latency, Cost for one service are peers. Fleet, Node, Process are levels. What must be shared is time range and scope. If a viewer sets a range on the Traffic page and moves to Errors to find a default six hours, they are comparing two different windows and will not notice. This is the single most common defect in the pattern and it is invisible in review because each page looks correct alone. What must not be shared is layout convention. Every page in the set should look like a member of the set—same header, same filter placement, same time control—because the value of a set is that learning one teaches you all of them. The other question is the landing page. A set with no obvious entry is a menu, and viewers pick whichever they used last. One of the pages should be an overview that says which of the others to open, which quietly turns the horizontal set back into a shallow hierarchy at the top. ## Use when The content genuinely divides into parallel questions, each substantial enough to fill a screen, and different roles or occasions call for different ones. ## Don't use when The pages are sequential steps of one investigation, where a hierarchy is honest and tabs will mislead. Also don't split when the real problem is that one page has forty panels nobody pruned; the fix is deletion, not filing. ## Trade-offs Splitting hides content behind navigation, and NN/g's warning holds: people ignore what they cannot see, so a page nobody lands on decays without anyone noticing. State synchronisation is genuinely hard, and every product gets some of it wrong. Cross-page comparison becomes impossible—two things that were adjacent are now a click apart, and the eye cannot hold a chart across a page load. And sets grow, because adding a page is easier than arguing about what to remove. ## Checklist - Are these pages peers, or are they actually levels of a hierarchy? - Does the time range carry across pages? - Do filters and scope carry across pages? - Do all pages share header, control placement and layout conventions? - Is there a landing page that says which of the others to open? - Can a viewer tell which page they are on without reading the title? - Do links from alerts land on the right page, with scope intact? - What happens to a page nobody has opened in six months? - Is anything on two pages, and do the copies agree? - Would deleting panels remove the need to split at all? ## Compare **Grafana** has no built-in page set: multi-page is separate dashboards in a folder, linked by dashboard links or a variable, so state sharing is whatever the author wired through the URL. That flexibility is why Grafana estates sprawl and why search becomes the navigation. **Datadog** scopes pages by tags at the page level, so moving between dashboards in the same scope keeps the filter, which solves the defect Grafana leaves to the author. **Sentry** organises horizontally by concern—Issues, Performance, Releases—with project scope carried across, which is the pattern working as product structure rather than as dashboard configuration. **Honeycomb** collects saved queries into boards, so a "page" is a curated set of questions and the sharing problem is smaller because each query carries its own parameters. **Cloudflare Radar** is this pattern with no state to share: eleven sections behind one rail, no account, and two page-level controls in the entire product. Moving between pages costs nothing because there was almost nothing scoped to carry, which is the version of the problem every tool above is solving the hard way. ## Related Tabs as genres is the specific case where the pages correspond to different kinds of question. Collapsible row is the lighter answer to try before splitting. Sidebar and canvas is how a set stays navigable. Overview then detail is the vertical alternative and the thing this is most often confused with. Saved view is what people build when the set does not match how they actually work. ## Examples ### Cloudflare Radar (Cloudflare) A public dashboard with no account, no filters worth the name, and an audience of journalists. Designed for people who will read one number and leave. **Worldwide Overview** — captured September 11, 2026, Public site, signed out; no version string exposed. public, medium density, light theme, desktop-web. Radar is a dashboard for people who did not come to use a dashboard. The audience is journalists, researchers and the merely curious, nobody has an account, and the design follows from that in two ways worth copying. Two controls scope the whole page—where, and when—and neither is a filter in the sense the rest of this gallery means it; the only other selector on the page sits inside the traffic panel. Everything else that looks like a control is a link. Each panel is a standing summary of a section that has its own full page behind the arrow in its heading, so the overview works as a table of contents rather than a filtered view of one dataset. And almost every value is printed as text above the chart that encodes it: "Bot 57.9%, Human 42.1%" sits over the bar rather than inside it. You can read the number without reading the chart, which is the right trade when most of your readers will take one figure and leave. Hotspots in this capture: - [Multi-page dashboard](https://patterns.konigi.com/dashboards/multi-page-dashboard) *(this pattern)* — Eleven sections behind one rail, with the open one expanded in place. Radar is a site of dashboards, not a dashboard. - [Compare periods](https://patterns.konigi.com/dashboards/compare-periods) — The dotted series is the previous seven days, drawn on the same axis rather than beside it. - [Overview then detail](https://patterns.konigi.com/dashboards/overview-then-detail) — Two summaries and an arrow each. The panel exists to tell you whether the full page is worth opening. - [Ratio and rate](https://patterns.konigi.com/dashboards/ratio-and-rate) — Shares only, never counts, and both sides of the split are named so the denominator is never in doubt. - [Stacked composition](https://patterns.konigi.com/dashboards/stacked-composition) — Four mitigation techniques to 100%. The bar is almost redundant next to the printed figures, which is the point. - [Ranked list](https://patterns.konigi.com/dashboards/ranked-list) — A top ten with no magnitudes at all. The rank is the whole finding. - [Delta indicator](https://patterns.konigi.com/dashboards/delta-indicator) — Eight shares with their change under them, all of them fractions of a point, which tells you how still this data is. ### Kibana (Elastic) Query-first rather than panel-first: the search bar is the primary control and the charts are downstream of it, which inverts Grafana's arrangement. **Dashboards / list** — captured September 10, 2026, Elastic demo environment (guest session). analytical, medium density, light theme, desktop-web. The estate, rather than a dashboard. Twenty rows a page and fourteen pages, so something close to 280 dashboards, and sixteen of the twenty on this first page are called "[Metrics Kubernetes] something"—Cronjobs, StatefulSets, Volumes, Pods, Deployments, Proxy, DaemonSets, Jobs, Nodes. They were generated by an integration rather than designed, they all landed on the same day, and they will sit in this list forever. That's the shape every mature dashboard estate takes, and it's why search stops being a convenience at this scale: nobody is browsing to page nine. The list does two things well. Each row carries a one-line description under the title, which is the difference between a name and an answer. And the bracket prefix is doing the work a folder would, so the generated ones sort together and stay out of the way of the four a person actually made. Hotspots in this capture: - [Multi-page dashboard](https://patterns.konigi.com/dashboards/multi-page-dashboard) *(this pattern)* — A set of peers with no landing page. Fourteen pages of them, and nothing says which is the one the team uses. - [Search across panels](https://patterns.konigi.com/dashboards/search-across-panels) — Past about fifty dashboards this is the navigation and the list below it is a filing system nobody browses. - [Semantic grouping](https://patterns.konigi.com/dashboards/semantic-grouping) — Tags and a bracket prefix standing in for folders, which is what keeps 250 generated pages out of the way. - [Data table](https://patterns.konigi.com/dashboards/data-table) — Name, description, last updated, actions. The description column is what makes this a list you can read rather than scan. ## Related patterns - [Tabs as genres](https://patterns.konigi.com/dashboards/tabs-as-genres) — The same data serves different questions and each deserves its own page. - [Collapsible row](https://patterns.konigi.com/dashboards/collapsible-row) — The dashboard grew to sixty panels and the viewer needs the top twelve most of the time. - [Sidebar and canvas](https://patterns.konigi.com/dashboards/sidebar-and-canvas) — Navigation between many dashboards needs to be persistent without stealing the canvas. - [Overview then detail](https://patterns.konigi.com/dashboards/overview-then-detail) — The viewer needs to start wide and end narrow without losing their place. - [Saved view](https://patterns.konigi.com/dashboards/saved-view) — The team re-selects the same five filters every morning. ## Sources - [Grafana, Manage dashboards](https://grafana.com/docs/grafana/latest/visualizations/dashboards/manage-dashboards/) - [Nielsen Norman Group, Progressive Disclosure](https://www.nngroup.com/articles/progressive-disclosure/) - [Bach et al., Dashboard Design Patterns](https://dashboarddesignpatterns.github.io/patterns.html) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.