Showback Dashboards

Production engineering guide for showback dashboards covering patterns, implementation strategies, and operational best practices.

Showback dashboards enable teams to visualize, track, and justify cloud spending across departments, projects, and services. They surface not just costs, but cost drivers, trends, and ownership patterns to inform decisions and foster accountability. These dashboards matter when cloud spend is no longer a centralized budget but a distributed, multi-team responsibility—when finance needs to see *who* spends *what*, and *why*, and engineering needs to see *how* cost patterns reflect their architecture choices.

Visualizing Cost by Team and Project

To present cloud spend to stakeholders, teams use dashboards that aggregate cost data from billing systems, tagging, and service metrics. The dashboard shows total cost per team or project, with drill-downs into service-level costs and time-series trends.

Data is pulled from a cloud billing API, often via an HTTP endpoint that returns JSON. A typical request uses GET /billing/costs?from=2024-03-01&to=2024-03-31&group=team.

{
  "costs": [
    {
      "team": "Backend",
      "total": 12470.32,
      "breakdown": [
        { "service": "EC2", "cost": 4120.15 },
        { "service": "RDS", "cost": 3215.80 },
        { "service": "S3", "cost": 2650.47 },
        { "service": "Lambda", "cost": 2483.90 }
      ],
      "trend": [
        { "date": "2024-03-01", "cost": 1010.20 },
        { "date": "2024-03-08", "cost": 1120.15 },
        { "date": "2024-03-15", "cost": 1230.40 },
        { "date": "2024-03-22", "cost": 1340.30 },
        { "date": "2024-03-29", "cost": 1410.25 }
      ]
    },
    {
      "team": "Data",
      "total": 8920.10,
      "breakdown": [
        { "service": "Redshift", "cost": 4500.00 },
        { "service": "Kinesis", "cost": 1800.20 },
        { "service": "S3", "cost": 1580.10 },
        { "service": "Glue", "cost": 1040.80 }
      ],
      "trend": [
        { "date": "2024-03-01", "cost": 820.50 },
        { "date": "2024-03-08", "cost": 835.40 },
        { "date": "2024-03-15", "cost": 850.30 },
        { "date": "2024-03-22", "cost": 880.10 },
        { "date": "2024-03-29", "cost": 910.20 }
      ]
    }
  ]
}

This data is consumed by a dashboarding tool—such as Grafana, Metabase, or Superset—via a JSON API. The dashboard renders a bar chart of team costs, with a line chart beneath showing the trend over time. Each bar is clickable, leading to a detailed view of cost per service, cost per instance, and active resource counts.

Common Pitfalls in Team-Based Costing

Dashboards must show not just *what* costs, but *how* they change—especially in response to releases, scale events, or infrastructure changes.

A time-series chart displays daily or weekly cost, with overlays for key events: deployment dates, peak traffic periods, or infrastructure migrations.

To generate this, a pipeline computes daily cost summaries and stores them in a time-series database. The query uses SELECT date, SUM(cost) AS daily_cost FROM cost_daily WHERE date >= '2024-01-01' GROUP BY date ORDER BY date.

The data is stored in a columnar format, such as Apache Parquet or InfluxDB. The dashboard tool queries this directly via SQL or HTTP.

SELECT 
  date,
  daily_cost,
  LAG(daily_cost, 7) OVER (ORDER BY date) AS weekly_cost,
  (daily_cost - LAG(daily_cost, 7) OVER (ORDER BY date)) / LAG(daily_cost, 7) OVER (ORDER BY date) AS weekly_growth
FROM cost_daily
WHERE date BETWEEN '2024-03-01' AND '2024-03-31'
ORDER BY date;

This query enables a dashboard to show cost growth over the past week, with a label indicating whether the current week is above, below, or on trend.

{
  "event": "deployment",
  "project": "user-service",
  "timestamp": "2024-03-20T14:30:00Z",
  "version": "v2.4.1",
  "author": "[email protected]"
}

But the dashboard does not map timestamp to the correct time axis. The event appears at the wrong time because the dashboard expects event_time instead of timestamp, or uses timestamp as UTC but expects the event to be in the dashboard’s default time zone.

Drill-Down to Service and Resource Level

A showback dashboard allows users to click on a team’s cost bar and view a breakdown by service. Each service shows cost over time, resource usage, and cost drivers.

For instance, clicking on EC2 in the Backend team reveals a detailed view of EC2 costs. The dashboard queries a services/EC2 endpoint:

GET /services/EC2?team=Backend&from=2024-03-01&to=2024-03-31

The response includes:

{
  "service": "EC2",
  "team": "Backend",
  "total_cost": 4120.15,
  "instances": [
    {
      "instance_id": "i-12345678",
      "type": "m5.large",
      "region": "us-west-2",
      "start_time": "2024-03-01T00:00:00Z",
      "end_time": "2024-03-31T23:59:59Z",
      "duration_hours": 720.5,
      "cost": 1140.20,
      "cpu_utilization": {
        "avg": 0.64,
        "min": 0.32,
        "max": 0.91
      }
    },
    {
      "instance_id": "i-87654321",
      "type": "t3.medium",
      "region": "us-east-1",
      "start_time": "2024-03-10T12:00:00Z",
      "end_time": "2024-03-31T23:59:59Z",
      "duration_hours": 504.7,
      "cost": 810.15,
      "cpu_utilization": {
        "avg": 0.42,
        "min": 0.15,
        "max": 0.75
      }
    }
  ],
  "cost_trend": [
    { "date": "2024-03-01", "cost": 120.00 },
    { "date": "2024-03-08", "cost": 150.20 },
    { "date": "2024-03-15", "cost": 180.50 },
    { "date": "2024-03-22", "cost": 210.30 },
    { "date": "2024-03-29", "cost": 240.10 }
  ]
}

This view helps teams understand not just *how much* they spend, but *why*. A spike in EC2 cost correlates with a new instance type, or high CPU usage, or a new service that runs only during peak hours.

Critical Subtle Failures

Making Showback Dashboards Actionable

A showback dashboard is not static. It must support filtering, comparisons, and exportability to drive decisions.

Users can filter by date range, team, service, or tag. The dashboard maintains state in the URL:

https://dashboard.example.com/showback?team=Backend&from=2024-03-01&to=2024-03-31&service=EC2&group=project

The dashboard updates the chart and table in response to query parameters. It also supports sharing via a link, and exporting the current view as CSV or PNG.

The Export Mechanism

When a user clicks "Export as CSV", the dashboard triggers a backend job that runs a query to generate the full dataset:

SELECT 
  team,
  service,
  instance_id,
  type,
  region,
  start_time,
  end_time,
  duration_hours,
  cost,
  cpu_utilization_avg,
  cpu_utilization_min,
  cpu_utilization_max
FROM cost_by_instance
WHERE team = 'Backend'
  AND service = 'EC2'
  AND start_time >= '2024-03-01'
  AND end_time <= '2024-03-31'
ORDER BY cost DESC;

The result is exported as a CSV file, with headers and formatted timestamps.

The export fails silently if the job takes longer than expected. The user clicks export, waits 30 seconds, but the file is missing. The root cause: the export job runs with a timeout of 30 seconds, but the query takes 35 seconds. The dashboard sends the request but does not wait for the result. The user sees a "Export started" message, but the file is not available.

The Hidden Failure: State Inconsistency

The dashboard stores user state (filters, selected views, drill-downs) in a database table:

CREATE TABLE dashboard_session (
  session_id VARCHAR(64) PRIMARY KEY,
  user_id VARCHAR(64),
  dashboard_name VARCHAR(64),
  filters JSON,
  last_updated TIMESTAMP,
  view_state JSON
);

But the view_state is not updated on every interaction. A user drills down into a service, changes the date range, but the view_state is only updated on page load. When the user navigates back, the drill-down is lost. The failure mode: the user clicks a link from a report, but the dashboard does not restore the previous state.

Summary

Showback dashboards are the living interface between cloud costs and organizational decision-making. They transform raw billing data into insights that drive accountability, planning, and optimization. Their effectiveness hinges on consistent data flow, correct time handling, accurate cost allocation, and seamless interaction. When these systems fail, the dashboard becomes a record of what *should* be, rather than what *is*.

This page was rewritten on 17 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.