Splunk Dashboard Studio

Splunk Dashboard Studio

Build production-quality dashboards using Dashboard Studio's JSON-based dashboard definitions. This skill covers the full definition schema, all visualization types, interactivity patterns, dynamic formatting, and design best practices.

Prerequisites

• Splunk MCP server connected for running queries and deploying dashboards
• For the existing Simple XML dashboard builder skill, see the splunk-dashboard-builder subagent type

Dashboard Definition Structure

Every Dashboard Studio dashboard is a single JSON object with these sections:

{
  "title": "Dashboard Title",
  "description": "Dashboard description",
  "inputs": {},
  "defaults": {},
  "visualizations": {},
  "dataSources": {},
  "layout": {},
  "expressions": {},
  "applicationProperties": {}
}

Workflow

When a user requests a Dashboard Studio dashboard:

Task Progress:
- [ ] Step 1: Understand the requirements (data, audience, purpose)
- [ ] Step 2: Design data architecture (searches, chains, tokens)
- [ ] Step 3: Select visualization types for each data element
- [ ] Step 4: Build the dashboard definition JSON
- [ ] Step 5: Add interactivity (inputs, tokens, drilldowns)
- [ ] Step 6: Apply dynamic formatting (DOS, conditional colors)
- [ ] Step 7: Deploy and validate

Step 1: Requirements Gathering

Ask or infer:

• What data/indexes are involved?
• Who is the audience? (SOC analyst, executive, engineer)
• What decisions should the dashboard support?
• Interactive or static? Grid or pixel-perfect absolute layout?

Step 2: Data Architecture

Design efficient SPL with base + chain searches:

"dataSources": {
  "ds_base": {
    "type": "ds.search",
    "options": {
      "query": "index=main sourcetype=access_combined | stats count by status, method, uri_path",
      "queryParameters": {
        "earliest": "$global_time.earliest$",
        "latest": "$global_time.latest$"
      }
    },
    "name": "Base Search"
  },
  "ds_by_status": {
    "type": "ds.chain",
    "options": {
      "query": "| stats sum(count) as total by status",
      "extend": "ds_base"
    },
    "name": "By Status"
  },
  "ds_by_method": {
    "type": "ds.chain",
    "options": {
      "query": "| stats sum(count) as total by method",
      "extend": "ds_base"
    },
    "name": "By Method"
  }
}

Data source types:

Step 3: Visualization Selection

Choose the right visualization for each data element. See viz-reference.md for the complete catalog with options.

Decision guide:

Step 4: Build the Definition

Visualization stanza pattern:

"viz_uniqueId": {
  "type": "splunk.column",
  "title": "Requests by Method",
  "description": "HTTP method distribution",
  "dataSources": {
    "primary": "ds_by_method"
  },
  "options": {
    "seriesColors": ["#7B56DB", "#009CEB", "#00CDAF"],
    "legendDisplay": "right",
    "stackMode": "stacked"
  },
  "containerOptions": {
    "title": { "color": "#FFFFFF" },
    "description": { "color": "#999A9C" }
  }
}

Layout: Grid vs Absolute

Grid layout:

"layout": {
  "globalInputs": ["input_time"],
  "tabs": {
    "items": [{ "layoutId": "layout_1", "label": "Overview" }]
  },
  "layoutDefinitions": {
    "layout_1": {
      "type": "grid",
      "options": { "width": 1440 },
      "structure": [
        { "item": "viz_sv1", "type": "block", "position": { "x": 0, "y": 0, "w": 300, "h": 150 } },
        { "item": "viz_sv2", "type": "block", "position": { "x": 300, "y": 0, "w": 300, "h": 150 } },
        { "item": "viz_chart", "type": "block", "position": { "x": 0, "y": 150, "w": 600, "h": 400 } }
      ]
    }
  }
}

Absolute layout adds: "display": "auto-scale", "backgroundColor", "backgroundImage", and "height" options.

Step 5: Interactivity

Inputs create tokens. Available types:

Input definition pattern:

"inputs": {
  "input_time": {
    "type": "input.timerange",
    "title": "Time Range",
    "options": {
      "token": "global_time",
      "defaultValue": "-24h@h,now"
    }
  },
  "input_host": {
    "type": "input.dropdown",
    "title": "Host",
    "options": {
      "token": "selected_host",
      "defaultValue": "*",
      "items": [
        { "label": "All Hosts", "value": "*" }
      ]
    },
    "dataSources": { "primary": "ds_hosts" }
  }
}

Token filters for safe interpolation in SPL:

Event handlers for drilldown:

"eventHandlers": [
  {
    "type": "drilldown.setToken",
    "options": {
      "tokens": [
        { "token": "selected_method", "key": "row.method.value" }
      ]
    }
  }
]

Other handler types: drilldown.linkToDashboard, drilldown.linkToUrl, drilldown.linkToSearch.

Default token values prevent empty panels on load:

"defaults": {
  "tokens": {
    "default": {
      "selected_method": { "value": "GET" }
    }
  }
}

Step 6: Dynamic Options Syntax (DOS)

DOS enables conditional formatting using the pattern:

"> [data source] | [selector] | [formatting function]"

Key formatting functions:

rangeValue example (single value delta coloring):

"options": {
  "deltaColor": "> deltaValue | rangeValue(deltaColorConfig)"
},
"context": {
  "deltaColorConfig": [
    { "from": 0, "value": "#1a9035" },
    { "to": 0, "value": "#dc4e41" }
  ]
}

Table column formatting with matchValue:

"options": {
  "columnFormat": {
    "severity": {
      "rowBackgroundColors": "> table | seriesByName(\"severity\") | matchValue(sevConfig)"
    }
  }
},
"context": {
  "sevConfig": [
    { "match": "critical", "value": "#DC4E41" },
    { "match": "high", "value": "#F8BE34" },
    { "match": "medium", "value": "#F1813F" },
    { "match": "low", "value": "#53A051" },
    { "match": "info", "value": "#0076D3" }
  ]
}

See viz-reference.md for the full DOS function catalog.

Step 7: Delegate to the Builder Subagent

Once you have gathered requirements (steps 1-3) and made design decisions, delegate the actual dashboard construction to the dashboard-studio-builder subagent. Pass it a build spec:

Build Spec:
- Title: <dashboard title>
- Description: <dashboard description>
- Audience: <SOC analyst | executive | engineer | etc.>
- Layout: <grid | absolute>
- Data sources:
  - Index: <index name(s)>
  - Sourcetype: <sourcetype(s)>
  - Key fields: <field1, field2, ...>
  - Time range default: <-24h, -7d, etc.>
- Visualizations needed:
  - <description of viz 1 + type if known>
  - <description of viz 2 + type if known>
  - ...
- Interactivity:
  - Inputs: <time range, dropdown filters, text search, etc.>
  - Drilldowns: <click-to-filter, link-to-dashboard, link-to-URL, etc.>
  - Conditional panels: <show/hide behavior>
- Formatting:
  - Severity coloring: <yes/no + field names>
  - Number formatting: <currency, percentage, units>
  - Table column formatting: <gradient, range colors, etc.>
- Deployment: <deploy via MCP | output JSON only>
- Special requirements: <any additional context>

The subagent handles data discovery via Splunk MCP, JSON assembly, deployment, and validation. It returns the complete dashboard definition and a summary.

If you prefer to build the JSON directly without the subagent, follow the schema and patterns documented in this skill and the reference files.

Expressions for Conditional Visibility

Show or hide panels based on conditions:

"visualizations": {
  "viz_detail": {
    "containerOptions": {
      "visibility": {
        "showConditions": ["cond_has_selection"]
      }
    },
    "type": "splunk.table",
    "dataSources": { "primary": "ds_detail" }
  }
},
"expressions": {
  "conditions": {
    "cond_has_selection": {
      "name": "Has selection",
      "value": "$selected_host$ != \"*\""
    }
  }
}

Application Properties

"applicationProperties": {
  "hideExport": false,
  "hideViewModeActionMenu": false,
  "hideEdit": false,
  "hideOpenInSearch": false,
  "collapseNavigation": false
}

Schema Validation Rules (MUST follow)

Dashboard Studio performs strict JSON schema validation on paste/save. These rules are enforced and will reject the dashboard definition if violated.

Option value types: string enums, not arbitrary values

Many visualization options that look like they should accept numbers or free-form strings actually require specific enum values. When in doubt, omit the option and let Splunk use its default.

splunk.singlevalue -- trendDisplay:

• Allowed: "percent", "absolute", "off", a $token$ reference, or a DOS expression ("> ...")
• NEVER use "sparkline" -- it is not a valid value despite appearing in older docs
• Sparkline-related sub-options (sparklineDisplay, showSparklineAreaGraph, sparklineValues, trendColor) are also invalid on splunk.singlevalue

splunk.column / splunk.bar -- xAxisLabelRotation:

• Do NOT set this option. There is no reliable numeric or string value that passes validation across Splunk versions.
• Splunk auto-rotates axis labels as needed. Omit the property entirely.

splunk.markdown -- fontSize:

• Allowed: "extraSmall", "small", "default", "large", "extraLarge", "custom", a $token$ reference, or a DOS expression
• NEVER use a raw number like 13 or a numeric string like "13"

"options": {
  "fontSize": "small"
}

Default token values must be strings

In the defaults.tokens.default section, every token value MUST be a string. This includes timerange tokens.

Wrong -- object value:

"defaults": {
  "tokens": {
    "default": {
      "global_time": {
        "value": { "earliest": "-24h@h", "latest": "now" }
      }
    }
  }
}

Correct -- string value:

"defaults": {
  "tokens": {
    "default": {
      "global_time": {
        "value": "-24h@h,now"
      }
    }
  }
}

For timerange tokens, the input.timerange defaultValue option (e.g. "-24h@h,now") handles setting .earliest and .latest automatically. If you also set a default token value, it must be a flat string.

General rule for option values

Every option value in a visualization must be one of:

1. A value from the option's allowed enum (check the schema)
2. A $token$ reference matching pattern $(\w+:)?([^$|:]+?)(\|[|\w]+)?$
3. A DOS expression string starting with >

If you are unsure whether a value is allowed, omit the option and let Splunk use its default. A missing option never causes a validation error; a wrong value always does.

Design Best Practices

1. Information hierarchy: Single values at top for KPIs, charts in middle for trends, tables at bottom for detail
2. Color discipline: Use Splunk's default palette. Reserve red for critical, green for healthy. Limit to 5-7 colors per chart.
3. Grid layout first: Use grid unless you need pixel-perfect placement or background images
4. Chain searches aggressively: One base search with multiple chains beats N independent searches
5. Default token values: Always set defaults so dashboards render meaningfully on first load
6. Title every panel: Every visualization should have a clear, descriptive title
7. Progressive disclosure: Use tabs for multi-topic dashboards, conditional visibility for detail panels
8. Standard canvas width: 1440px for absolute, 1200px for grid
9. Consistent spacing: Use multiples of 8px for gutters and margins

Builder Subagent

The dashboard-studio-builder subagent (~/.cursor/agents/dashboard-studio-builder.md) handles the full build lifecycle:

1. Data discovery via Splunk MCP (indexes, sourcetypes, fields)
2. JSON definition assembly with all sections
3. Deployment to Splunk via MCP (if available)
4. Structural validation (viz-to-layout, datasource refs, token consistency)

Invoke it with the build spec template from Step 7 above. The subagent has the complete Splunk UI Design System standards baked in -- color palette, accessibility rules, and information hierarchy patterns.

Additional Resources

• Complete visualization type catalog and options: viz-reference.md
• Full dashboard definition examples: examples.md
• Splunk docs: https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/dashboard-studio/
• Splunk UI Design System: https://splunkui.splunk.com/DesignSystem/Overview