A monitoring account needs visibility into server activity, not a master key to the instance. VIEW SERVER STATE and the newer focused permissions let you grant useful access without adding a login to sysadmin.
List the Questions First
What must the colleague or tool read? Name the DMVs, metadata, and msdb job history it needs. I start with that list because a broad grant can look convenient until a security review asks why it exists. VIEW SERVER STATE covers many server DMVs on older versions. SQL Server 2022 separates important areas into VIEW SERVER PERFORMANCE STATE and VIEW SERVER SECURITY STATE. The exact DMV documents its required permission. A tool that reads only performance state should not receive security state by habit.
VIEW ANY DEFINITION exposes object definitions across the instance. Give it only when the workflow truly needs text or metadata that is otherwise hidden. Monitoring without query text can be enough for one tool, while another needs it to diagnose plans.
Create a Dedicated Principal
Use a dedicated Windows or managed identity where your environment supports it. Keep human access separate from service access so audit records have meaning. The example is a template for a domain principal; replace the name with your approved identity. It starts with USE master because a server-level GRANT run from any other database fails with error 4621. Do not create a shared SQL login with a password copied into a setup document. Name the purpose in the login description or access request, and record who owns it.
USE master;
CREATE LOGIN [CORP\SqlMonitor] FROM WINDOWS;
GRANT VIEW SERVER PERFORMANCE STATE TO [CORP\SqlMonitor];
GRANT VIEW ANY DEFINITION TO [CORP\SqlMonitor];
-- Grant only if the monitoring queries need security-state DMVs:
-- GRANT VIEW SERVER SECURITY STATE TO [CORP\SqlMonitor];Choose VIEW SERVER STATE or Its Newer Split
On SQL Server 2022 and later, test the narrower performance and security grants against the exact queries the tool runs. On those versions VIEW SERVER STATE includes both focused permissions, so granting it hands over the security side as well. On earlier versions it remains the broad grant most server DMVs require. Read the permission line for each view. I run the monitoring tool in a test environment after granting the smallest set and add only what a failed query proves necessary.
The script below impersonates the monitoring login and reports its effective grants. Start it from master, because impersonating the login inside a database where it has no user fails with error 916. With only the grants above, the row reads 0, 1, 0, 1. That output answers what SQL Server sees, which is more useful than a ticket claiming access was granted.
USE master;
EXECUTE AS LOGIN = 'CORP\SqlMonitor';
SELECT HAS_PERMS_BY_NAME(NULL, NULL, 'VIEW SERVER STATE') AS view_server_state,
HAS_PERMS_BY_NAME(NULL, NULL, 'VIEW SERVER PERFORMANCE STATE') AS view_performance,
HAS_PERMS_BY_NAME(NULL, NULL, 'VIEW SERVER SECURITY STATE') AS view_security,
HAS_PERMS_BY_NAME(NULL, NULL, 'VIEW ANY DEFINITION') AS view_definitions;
REVERT;Add Only the Job History Needed
SQL Agent history lives in msdb. SQLAgentReaderRole can read jobs and their history more broadly than SQLAgentUserRole. Add the database user to that role only if the tool needs cross-job visibility. Create the corresponding user in msdb first. Review any job steps that expose command text, proxy names, or operational details. Job history can contain sensitive error messages. The role is useful, but it is not a decorative checkbox.
USE msdb;
CREATE USER [CORP\SqlMonitor] FOR LOGIN [CORP\SqlMonitor];
ALTER ROLE SQLAgentReaderRole ADD MEMBER [CORP\SqlMonitor];
Test What the Login Cannot Do
Connect as the monitoring identity and run the approved read queries. Then attempt a harmless denied operation in a test environment, such as changing a server setting or reading a security DMV without its grant. Capture the error and confirm no privilege path grants unexpected control through role membership. I inspect sys.server_role_members and explicit server permissions as part of that check. A login can inherit rights from a group that the setup script never mentions.
Ask whether the tool really needs to enumerate all database definitions. If not, replace VIEW ANY DEFINITION with narrower database-level grants where practical. The least privilege design is the one tested against the actual workload, not the smallest-looking script.
Verify Effective VIEW SERVER STATE Access
A grant listed in sys.server_permissions can be offset by a DENY, inherited through a Windows group, or irrelevant to the DMV the tool really reads. Connect as the monitoring principal and execute its exact collection queries. Record failures with the required permission text from the installed SQL Server version. I also test an ordinary application login to ensure the new access was not granted through a broad group. Server role membership deserves a separate review, since an identity can inherit sysadmin from a group even when the new setup script looks modest.
Run a harmless negative test in a nonproduction instance. Attempt a server configuration change or another operation the monitor must not perform. The failure should be clear. Do not conduct a destructive permission test against production. I keep the test script with the access request so the next upgrade can repeat it. Permissions are only least privilege when both the required reads and the forbidden writes have been checked.
Keep Job Visibility Narrow
SQLAgentReaderRole can see job metadata and history across msdb. Some jobs contain command text, file paths, and operational details that are sensitive even though the role does not grant sysadmin. Decide whether the monitoring tool needs all jobs or only a defined subset. If the requirement is narrower, an approved reporting procedure or tailored msdb access design can expose just the needed status. I review the job text before adding a human backup login to the role.
What will happen when the colleague's coverage period ends? Put an expiration or review date on temporary access. For a service account, set an owner and rotation plan. I check usage before removing an old grant, then remove it in a controlled change. A login left with broad read access for years can become a quiet information channel long after the monitoring task has changed.
Keep VIEW SERVER STATE Grants Reviewable
Record the principal, purpose, owner, permissions, version-dependent rationale, and a review date. Remove old monitoring identities when the tool is retired. Re-test after upgrades because permission requirements and tool queries change. A short read-only smoke test after patching is far cheaper than learning at midnight that the monitoring job silently stopped collecting useful data.
I prefer an access script that can be rerun in a test environment and a matching removal script. Put the grants in change control with the monitoring configuration. That gives the next DBA a way to answer both questions: why does this login have access, and what breaks if it is removed?
Related reading on this blog: Understanding Grant, Deny, and Revoke Permissions and A Quarterly Permission Review.
Monitoring access is not administration access, it is a set of specific questions the login can answer.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
