skip to content

In Kibana, what actually has to travel with a dashboard for it to work in another space or another cluster?

level: seniorimportance: nice to knowfreq 22%

answer

  1. Dashboards are stored by Kibana itself
  2. It points at things by id
  3. References must exist in the target
  4. Export with related objects, not alone
  5. Each space gives objects their own ids

basics

~20 s

A Kibana dashboard is a saved object that points at other saved objects by id: its panels and the data views behind them. Export it without those references and it imports cleanly but renders nothing.

solid answer

~50 s

A Kibana dashboard is a **saved object**: an id, a type, attributes, and a list of **references** to other saved objects — the panels it shows and the data views those panels query. It is a node in a graph, not a self-contained file, so exporting the dashboard alone gives you something that imports without error and shows nothing. What has to travel is the dashboard plus every object it references, exported together as newline-delimited JSON. **Spaces** matter because each space holds its own objects: an identically titled data view in the target space has a different id, so the reference dangles until you import the view too or remap it during import. Another cluster adds two conditions — the indices the data view names must exist there, and the Kibana versions must be compatible. Treat it as a deploy step: export with references, commit the file, import through the API.

code

json · 1 line
json
{"type":"dashboard","id":"hearing-latency","attributes":{"title":"Hearing scheduling latency"},"references":[{"type":"lens","id":"adjournments-by-room"},{"type":"index-pattern","id":"court-hearings"}]}

go deeper

for a junior

Know that a Kibana dashboard is a saved object stored by Kibana rather than in your log indices, and that it can be exported to a file and imported elsewhere.

for a middle

Explain that a dashboard points at its panels and data views by id, and that an export has to include those related objects or the import lands with panels that render nothing.

for a senior

Be ready to promote a dashboard between spaces or clusters as a repeatable step: export with references, keep ids stable, import through the API, and confirm the target has matching indices.

for a principal

Own whether dashboards are reviewable artefacts in version control or things people click together, and be able to price the drift between environments that the second choice guarantees.

## What a saved object is Kibana keeps its own furniture — dashboards, Lens visualizations, saved searches, data views, alerting rules — as **saved objects** in its own system index, entirely separate from the indices your data lives in. Each one carries: - a **type** (`dashboard`, `lens`, `search` for a saved search, `index-pattern` for a data view, and others); - an **id**, unique within its space; - **attributes**, the object's own configuration; - **references**, a list of the other saved objects it depends on, each named by type and id. That last field is the whole answer to this question. A dashboard is not a self-contained document. It is a node in a small graph, and moving the node without its edges produces something that imports cleanly and renders nothing. ## The reference graph of one dashboard A dashboard references its panels, and its panels reference the data view they query. Panels come in two shapes, and they are not equivalent when you move them: | | By-reference panel | By-value panel | | --- | --- | --- | | Where the configuration lives | in its own saved object | inside the dashboard object | | Reusable on other dashboards | yes | no | | Editing it changes every use | yes | no | | What must exist in the target | the panel object and its data view | the data view only | Neither shape is wrong. By-reference panels are how a team keeps one definition of "hearings that started late"; by-value panels are how a dashboard stays a single portable object. What matters when you promote a dashboard is knowing which ones you have, because they need different things to exist on the other side. ## Moving to another space Spaces are not folders over one shared pile of objects: each space holds its own. A data view titled `court-hearings-*` in one space and an identically titled view in another are two different objects with two different ids, and a panel that references one of them by id will not find the other. Kibana offers two routes — copy a set of objects to another space, or export them to a newline-delimited JSON file and import that. Both can bring the referenced objects along, and both have to decide what to do about collisions: overwrite what is already there, or create fresh copies with new ids. Import also surfaces the references it could not resolve and lets you point them at an object that does exist, which is the manual repair for exactly the failure above. ## Moving to another cluster Everything from the space case, plus two conditions that have nothing to do with Kibana's own state: - **The indices have to exist.** A data view is a pattern, not data. Import a dashboard into a cluster where nothing matches `court-hearings-*` and every panel is correct, wired up, and empty. - **The Kibana versions have to be compatible.** An export from a newer Kibana is not guaranteed to import into an older one, so promote in the same direction you upgrade. Nothing about the documents travels. You are shipping definitions, and the definitions assume a world on the other side. ## Why this is a deployment concern, not a UI one Take the courtroom-scheduling platform that brought up a new region with no instrumentation and turned its shippers on three weeks later. The hearing-latency dashboard — 9 panels, 3 data views, 41 saved objects once references are pulled in — now has to exist in the new region's space. Rebuilt by hand it costs an afternoon and drifts within a week; clicked through the copy dialog by three different people it produces duplicate data views nobody can tell apart. Treated as a deployment it is five steps: 1. Export the dashboard **with its related objects**, as one newline-delimited JSON file. 2. Commit that file beside the code whose behaviour it visualises, so a change to it is reviewable. 3. Import it in a deploy step through Kibana's API rather than by hand. 4. Keep ids stable across environments so an import updates the existing objects instead of multiplying them. 5. Check that the target actually has matching indices before calling it done. ## What an interviewer is listening for - That a dashboard is a **reference graph**, not a file. - That **ids, not titles**, are what a reference resolves against. - That **spaces isolate** objects, so "it works in mine" says nothing about another team's. - That promoting a dashboard is a repeatable, reviewable step — and that the alternative is how two environments quietly stop measuring the same thing.

  • What is the difference between a by-value and a by-reference panel on a Kibana dashboard, and which one travels better?
    A by-reference panel points at its own saved object, so several dashboards share one definition and editing it changes them all. A by-value panel keeps its configuration inside the dashboard object, so it cannot be reused but it moves as part of a single object. For promotion, by-value means fewer references that can dangle; for shared definitions, by-reference wins.
  • An import succeeds, but every panel reports that its data view is missing. What went wrong?
    The dashboard's panels reference a data view by id, and the target space has its own view — same title, different id — so the reference resolves to nothing. Either export and import the data view alongside the dashboard so the ids match, or use the import flow's conflict resolution to remap each dangling reference onto the view that already exists there.

Exporting the dashboard alone is like sending a spreadsheet full of formulas that reference workbooks you left on your own machine.

saying these in an interview costs you the question

  • Thinks copying the dashboard object alone is enough
  • Assumes data views are shared across every space
  • Believes saved objects live in the log indices themselves
  • Expects a dashboard to work where no matching indices exist
  • Treats promotion as click-through work, never a deploy step