1. Dashboards intermediate

    A platform has hundreds of dashboards and engineers cannot find the right one during an incident. How should dashboards be structured?

    2 min answer dashboardsincident-responsehierarchybooking
  2. Dashboards intermediate

    Design the one dashboard your team opens first during an incident. What is on it and what is deliberately not?

    2 min answer dashboardsincident-responsedesignobservability
  3. Dashboards intermediate

    Review this incident dashboard. One page holds 28 panels, the default range is 6 hours, auto-refresh is 10 seconds, the scrape interval is 30 seconds, and every panel plots a 5-minute rate over per-pod series for a 900-pod fleet. During the last incident the page took 40 seconds to load and two panels timed out. What would you remove, what would you change, and what would you leave alone?

    3 min answer dashboardsquery-costresolutionincident-response
  4. Dashboards intermediate

    Review this: the payments team's primary dashboard has 62 panels on one page — CPU, memory, disk and network for each of 9 services, JVM heap and GC for each, connection-pool gauges, Kafka consumer lag, and three panels at the bottom showing authorisation rate, settlement latency and decline reasons. On-call says it is "comprehensive". The last two incidents were diagnosed from logs. What do you remove, what do you change, and what do you leave alone?

    4 min answer dashboardson-callgolden signalsalert design
  5. Dashboards intermediate

    Your metrics pipeline normally makes data queryable about 20 seconds after it is emitted. During a large incident the ingestion tier falls behind and the lag grows to four minutes. Nothing is lost. Walk through what happens to the on-call engineer's decisions.

    3 min answer telemetry lagincident responserollbackalerting