Dashboard Refresh Turns a Question into a Platform Incident
At 09:10 the Tanium Server CPU jumps to 95% and stays there. The operator who came on shift at 09:00 had saved a question called Full Inventory with 14 sensor columns, including a PowerShell script that enumerates installed MSIs and a WMI query for logical disks. It targets All Computers (21,400 endpoints) and is set to refresh every 3 minutes in a dashboard. Within 20 minutes, 6,000 clients report CPU above 40%, and the dashboard shows results pending for most rows. A second operator's simple two-sensor question now takes 11 minutes instead of 40 seconds.
1. What question-design factors are most likely driving the load, and what evidence would you collect before changing the question?
Read the worked answer
The load is a product of columns x endpoints x refresh rate, not just endpoint count. 14 columns on 21,400 endpoints is already a large question; two of those columns are expensive because one starts a PowerShell process and one queries WMI. A 3-minute dashboard refresh multiplies that work continuously and keeps clients busy. Evidence: check question history for issue time, duration, and result count; compare with the two-sensor question; look at client CPU on a sample; temporarily pause the dashboard refresh and observe server CPU; run the same question against a 200-endpoint pilot group. Do not assume the server is undersized until you have separated question cost from infrastructure.
2. How would you redesign the question to meet the inventory need without harming the platform?
Read the worked answer
Split by purpose. Keep a cheap saved question with identity and OS columns for broad targeting, and put the MSI enumeration in a separate question that runs on a narrow computer group, on a slower schedule, or as a package-based inventory job. Replace the WMI disk query with a cheaper sensor if one exists, or accept a longer cache. Target a managed-workstation group instead of All Computers. Reduce dashboard refresh to daily or remove auto-refresh; dashboards should not drive high-cost questions every 3 minutes. Test the redesign on 200 endpoints and compare server CPU, client CPU, and completion time before widening.
3. What guardrails would you put in place to prevent a repeat?
Read the worked answer
Add a review step for saved questions that will be dashboarded: number of columns, sensor cost, target group, and refresh interval. Cap dashboard refresh for questions above a cost threshold. Use pilot groups for new high-cost sensors. Alert on Tanium Server CPU, question duration, and client resource spikes. Train operators that a saved question is an operational object, not a personal filter, and require owners to document why each column is needed. Periodically review dashboards for questions that no longer justify their cost.