Know what your SQL Servers are doing, before your users tell you.
VS Code, desktop and command line. Windows, Mac and Linux. One licence covers all three.
A collector you run on your own network checks SQL Server, Azure SQL and Amazon RDS on a schedule, keeps the history in a database you choose, and alerts you by email, Teams or Slack. See every server at a glance in VS Code and on the desktop.
Make a project of the servers to watch and see every one as a card in its group, coloured green, amber or red, with a small line each of its waits, CPU and disk I/O over the last hour. The latest alerts sit beside the cards, the newest first, and a card or an alert opens its server.
CPU, memory, waits, blocking, deadlocks, long queries, disk space, log space, backups, failed jobs and availability groups. Each area has a state and a summary in plain words, with its details: the sessions blocked and who blocks them, each deadlock's victim, the databases that need a backup, the jobs that failed. Checks only read the server's own views, wait no longer than 5 seconds for a lock, and give way in a deadlock, so they never stop the server's own work.
Every check samples the server for a second: batch requests, transactions, compilations, connections, tasks waiting, page life, page splits and more. Each is a tile with a small line of the last hour, so you see at once whether now is normal.
The collector runs as a Windows service, a Linux systemd service, a Mac daemon or in Docker, checks every server on its schedule and keeps each check in a database of yours, for as many days as you say. Chart SQL Server's CPU, memory and throughput together, with the same time last week dashed beneath, then its free disk and blocked sessions, and open any past check in full.
See a server's top queries by CPU, time, reads, writes or runs, in all or per run, and click one for all of its text and its plan: from the plan cache now, from a database's Query Store with what each waited on, or from what the collector kept, so a query that only runs at night still shows.
Show a query's plan as a tree of operators, each with its share of the cost and a bar, the costly ones in red. Warnings are in plain words, such as a spill to tempdb or a type conversion, and each missing index comes with its CREATE INDEX statement to copy. Save the plan as a .sqlplan for SQL Server Management Studio.
The Sessions tab lists the user sessions, those holding others up first: who each is, what it runs and waits on and for how long, its CPU and open transactions, and who blocks it. The session at the head of a chain is red, the sessions it holds up amber.
The Data I/O tab lists every database file with its size, reads, writes and the average time each took since SQL Server started, the slowest first. A file is amber at 20 ms and red at 50 ms on average, once there are enough reads or writes to judge.
The Backups tab shows each database's last 31 days, a square a day: green a full backup, blue a differential, pale log backups only. A database never backed up is red, one whose last full backup is over a week old amber, as is one in full recovery with no log backup in a day.
The Versions tab shows the releases your servers run as a ring, how many are behind the latest cumulative update, and each server with its update, its build and what to do: current, a security update short, behind by how many, or out of support. Azure keeps itself up to date, and says so.
Each server's release, patch level and when its support ends, its settings, databases and most powerful logins, and what best practice says about them, worst first: a release out of support, xp_cmdshell on, max server memory not set, a database that shrinks itself, the sa login turned on.
Sixteen built-in rules: server down, restarted, each area's warning or critical, failed jobs, SQL Server Agent stopped, checks that failed and the history store down. An alert is said when it fires, again on a schedule while it stays, at once when it gets worse, and once it is fine again. Each channel hears warnings or only critical alerts.
The Estate view lists every .monitor.json project in the workspace with its servers coloured by how they are, and the Alerts view the alerts the store keeps open. Open Overview for the cards and the Versions tab, or click a server for its page: health, activity, top queries with plans, inventory, history, data I/O, sessions and backups.
A project is a .monitor.json file: the servers, each in a group if you like, the history store, how the collector runs, the limits each area is judged by and the alert channels. It never holds a password or a secret: SQL login passwords, SMTP passwords and webhook addresses are kept only in the system's secure store. Test project signs in to everything as the collector would, and says what needs a look before you install the service.