Finding the expensive query is half the job. The other half is the execution plan, and the usual workflow for that half involves copying XML into SSMS and squinting. The built-in plan viewer removes the trip: click a collected query, and the plan the monitor captured renders in-app, already analyzed.
Native ShowPlan rendering with the analyzer’s findings and an operator-level breakdown beside the diagram.
The 30-Rule Analyzer
Every plan that opens gets run through a 30-rule analyzer that flags the things you’d actually hunt for by hand: implicit conversions, spills, residual predicates, parameter sensitivity, missing indexes with usable predicates, expensive operators, and the rest of the greatest hits. The operator-level cost breakdown sits next to the diagram, and a minimap keeps a 400-operator monster navigable. On actual plans, per-operator runtime stats are right there, which beats estimated percentages every time someone’s tempted to trust them.
Three Clicks From Problem to Plan
The drill path is the feature. Find a query in the Queries grids, Query Store, or FinOps, right-click, View Plan, and the stored plan opens as a sub-tab. Active query snapshots carry per-row Estimated and Actual plan buttons. Top Queries rows include a download button that saves the stored plan as a .sqlplan file when you want to share it. Plans open as closable sub-tabs, so comparing three candidates side by side is just three tabs.
Standalone Mode
The viewer also works with no server connection at all: drag a .sqlplan file onto the window, or paste plan XML straight from a clipboard, and it renders and analyzes the same way. A plan someone attached to a ticket gets the same treatment as one the monitor captured.
Edition Notes
The same plan-viewer control ships in Lite and the Darling viewer. The Darling viewer renders plans the service captured and stored; it never opens a connection to your monitored servers, so live plan fetches (“get me the actual plan right now”) are a Lite feature, where the app owns a direct connection. Blocked-process and deadlock rows carry a sql_handle rather than plan XML, so those grids don’t offer a plan jump; the query grids do.
The MCP surface runs the same analyzer over stored plans, so an AI assistant can read the same findings you see. See the MCP docs.
PerformanceMonitor on GitHub · monitoring overview