SQL Server Agent Will Not Start, or “Agent XPs Component Is Turned Off” (Error 15281)

Jobs stopped running, or the SQL Server Agent node in Object Explorer is greyed out, or a call to sp_start_job came back refusing to do anything. There are 3 different faults behind those symptoms and they need different fixes, so the first job is telling them apart.

Start Here: Is the Service Actually Running

One query answers it, and it answers the startup type and the service account at the same time, which you will want in a minute. No Configuration Manager, no remote desktop to the box.

SELECT servicename,
       status_desc,
       startup_type_desc,
       service_account
FROM   sys.dm_server_services;

servicename                         status_desc  startup_type_desc  service_account
----------------------------------  -----------  -----------------  --------------------------
SQL Server (MSSQLSERVER)            Running      Automatic          NT Service\MSSQLSERVER
SQL Server Agent (MSSQLSERVER)      Running      Automatic          NT Service\SQLSERVERAGENT
SQL Server Launchpad (MSSQLSERVER)  Running      Automatic          NT Service\MSSQLLaunchpad

Two columns decide the rest of the page. If the Agent row says Running, the service is fine and the problem is the surface area setting covered next. If it says Stopped, skip the sp_configure advice entirely, because it will not start a service, and go to the Agent error log for the reason it stopped. If there is no Agent row at all, check the edition. The view is documented on MS Docs under sys.dm_server_services.

Error 15281: The Agent XPs Component Is Turned Off

This is the message behind the greyed-out node, and it is the one most people arrive with. It is not specific to the Agent: the same number covers xp_cmdshell and Database Mail, and the component name inside the text is what tells you which one was blocked.

That is the row as the engine stores it, placeholders and all, and it is worth seeing once because it explains the shape of the line in front of you. %S_MSG is filled with the object type and the rest with the names, so what a client actually prints reads SQL Server blocked access to procedure ‘dbo.sp_start_job’ of component ‘Agent XPs’. When you search, search on “of component” plus the component name rather than the object name, because the object changes with whatever you happened to run.

The fix is 4 statements, and it takes effect immediately with no service restart and no instance restart.

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
EXEC sp_configure 'Agent XPs', 1;
RECONFIGURE;
GO

-- Prove it landed. value_in_use is the column that matters, not value.
SELECT name, value, value_in_use
FROM   sys.configurations
WHERE  name = 'Agent XPs';

Agent XPs is an advanced option, which is why the first 2 statements are there at all. Then read value_in_use rather than value: value is what you asked for, value_in_use is what the engine is running, and the 2 disagree whenever a RECONFIGURE was skipped. If you turn the option on for a diagnosis, put it back the same way and confirm with the same SELECT.

Why It Was Off, and the Part Most Advice Gets Wrong

The default for Agent XPs is 0. MS Docs is blunt about what that costs you in the tool: “Management Studio Object Explorer doesn’t display the contents of the SQL Server Agent node unless these extended stored procedures are enabled regardless of the SQL Server Agent service state” (Server Configuration: Agent XPs on MS Docs). Read that last clause twice. The node is a picture of the setting, not a picture of the service, so an Agent that is running perfectly can show you nothing, and an Agent that is stopped can still show a full job list.

It runs the other way too, and this is the half that costs people an outage. Setting Agent XPs to 0 on an instance whose Agent service was Running blocked nothing: sp_start_job succeeded and reported Job ‘syspolicy_purge_history’ started successfully, both for a sysadmin and for a login whose only right was SQLAgentOperatorRole in msdb, and sp_help_jobactivity returned its normal rows throughout. Measured on SQL Server 2025, build 17.0.4075.5. The useful consequence is this: if you are genuinely seeing 15281, the service is very probably not running, so apply the sp_configure fix and then go back and check the service state rather than declaring it solved.

As for how it came to be off, 3 causes cover nearly all of it.

• A fresh install or a rebuilt instance. The option ships at 0, so a server nobody configured has never had it on. Starting the Agent service from SSMS enables the procedures as a side effect, which is why the setting stays invisible until somebody starts the service with net start or Configuration Manager instead.
• SQL Server Service Will Not Start: Error 17113, 17058, 1067 and Where the Real Reason Is, fix the engine first when both the service and the Agent are down
• A surface area policy put it back. Policy-Based Management and the secure defaults described under surface area configuration on MS Docs can reset these options on a schedule, so the symptom returns days after you fixed it. Documented rather than reproduced here, and it is the cause to suspect when the fix does not stick.
• An edition change. Move an instance to Express and the Agent is gone rather than merely disabled, which is its own section below because no amount of sp_configure brings it back.

One popular cause you can cross off: restoring msdb does not turn Agent XPs off. It is a server-level option, and sys.configurations returns the same row with the same configuration_id from every database context, so it is not carried inside an msdb backup. What an msdb restore really does to the Agent is leave msdb unavailable or mismatched at startup, which looks nothing like 15281 and lands in SQLAGENT.OUT instead.

“SQLServerAgent Is Not Currently Running So It Cannot Be Notified Of This Action”

This is the other line that sends people here, usually after a sp_start_job call or a right-click Start Job in SSMS, and it is commonly reported with the number 22022. It is a plainer message than 15281 and it means exactly what it says, but there are 2 things worth knowing before you spend any time on the number.

SQLServerAgent is not currently running so it cannot be notified of this action.

First, do not go looking for it in sys.messages, because it is not there. On SQL Server 2025, build 17.0.4075.5, a search of sys.messages for the phrase “SQLServerAgent is not currently running” returns 0 rows in every language, and message_id 22022 itself holds a completely unrelated message, “An internal error occurred while getting physical foreign file size”, at severity 21. The text comes from the Agent notification path instead of the message catalogue: sp_start_job calls msdb.dbo.sp_sqlagent_notify, which calls the extended procedure xp_sqlagent_notify, and that is the layer that reports the service is not listening. Both calls were confirmed present in the msdb module definitions on the same build.

Second, and more useful mid-incident, the number is a dead end but the message is not. It is the clearest symptom on this page, because it can only mean the service is down. Nothing in sp_configure fixes it. Go to the service state query to confirm, then to SQLAGENT.OUT for the reason, and if the service will start but every job then fails on its own terms, that is a different problem covered in SQL Agent Job Failed.

The Service Account and the Startup Type

Two of the commonest reasons an Agent service does not come back are already sitting in the output from the first query, in the 2 columns most people skip.

startup_type_desc explains the server that was fine until it rebooted. If it reads Manual or Disabled, the Agent did not fail, it was never asked to start, and no amount of starting it by hand survives the next restart. The engine service is almost always Automatic and the Agent is the one that gets left behind, usually after an install where somebody accepted the defaults. Set it to Automatic and the symptom stops recurring.

service_account explains the server that stopped overnight. A domain account with an expired or rotated password is the classic, and the service will refuse to start with a Windows service-control error long before SQL Server gets a word in, which is why there is nothing in the SQL Server error log to find. The default virtual accounts, NT Service\SQLSERVERAGENT in the capture above, have no password to expire, which is the reason MS Docs recommends them over a named account unless the Agent genuinely needs to reach something off the box. If you must change the account, change it in Configuration Manager and not in the Services applet, because Configuration Manager grants the rights and file permissions the Agent needs and the Services applet does not. MS Docs covers the choice under Select an Account for the SQL Server Agent Service.

Express Edition Has No Agent At All

Worth ruling out in 10 seconds, because the symptom is indistinguishable from a disabled one and every fix on the internet will fail on it. If there was no SQL Server Agent row in the service query, ask the instance what it is.

SELECT SERVERPROPERTY('EngineEdition')  AS EngineEdition,
       SERVERPROPERTY('Edition')        AS Edition,
       SERVERPROPERTY('ProductVersion') AS ProductVersion;

EngineEdition returns 4 for Express, and that is your answer. The instance in the captures above returns 3 with an Edition of Enterprise Developer Edition (64-bit), which is the Enterprise code path. The values are listed on MS Docs under SERVERPROPERTY, and the edition feature table is unambiguous about the component itself: SQL Server Agent is Yes for Enterprise, Standard and Web, and No for Express and for Express with Advanced Services (Editions and supported features on MS Docs). Database Mail is absent on the same terms, which is why Express instances also cannot send job-failure notifications.

There is no workaround inside SQL Server. Scheduling on Express means Windows Task Scheduler driving sqlcmd, or moving the workload to an edition that has an Agent. If you are not sure what edition the rest of the estate is running, Get Edition Feature Usage answers it for every instance at once and flags the features already in use that a downgrade would break.

Read the Agent’s Own Log, SQLAGENT.OUT

When the service will not start, the SQL Server error log usually has nothing, because the Agent is a separate process with its own log. Find it without leaving the query window. Both of these return the same path, and the second one works even when the Agent procedures are blocked.

-- The Agent's own view of its configuration, including the log path.
EXEC msdb.dbo.sp_get_sqlagent_properties;

-- The same value straight from the registry, instance-aware.
DECLARE @path nvarchar(520);
EXEC master.dbo.xp_instance_regread
     N'HKEY_LOCAL_MACHINE',
     N'SOFTWARE\Microsoft\MSSQLServer\SQLServerAgent',
     N'ErrorLogFile',
     @path OUTPUT,
     N'no_output';
SELECT @path AS ErrorLogFile;

-- And the contents, without opening the file. 2 = the Agent log.
EXEC sp_readerrorlog 0, 2;

On the instance in these captures the errorlog_file column and the registry value both return C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\Log\SQLAGENT.OUT. The MSSQL17 part is the instance folder, so never hard-code the path across an estate, and note that the Agent keeps far less history than the engine does: the log on that instance held 199 lines covering a little over a day.

A healthy startup looks like this. The timestamp column is trimmed here for width, and the bracketed numbers are the Agent’s own message ids, which are the part worth searching on.

[432] There are 7 subsystems in the subsystems cache
[000] InitDefaultMSDBId initialized default msdb id to 4.
[339] Local computer is HPAI01 running Windows 10 Home 10.0 (26200)
[310] 8 processor(s) and 7969 MB RAM detected
[103] NetLib being used by driver is DBNETLIB; Local host server is HPAI01
[102] SQL Server ODBC driver version 18.06.002
[101] SQL Server HPAI01 version 17.00.4075 (0 connection limit)
[393] Waiting for SQL Server to recover database 'msdb'...
[495] The SQL Server Agent startup service account is NT Service\SQLSERVERAGENT.
[100] Microsoft SQLServerAgent version 17.0.4075.5 (X64 unicode retail build) : Process ID 8704
[508] Logging SQL Server Agent messages in file 'C:\Program Files\Microsoft SQL
      Server\MSSQL17.MSSQLSERVER\MSSQL\Log\SQLAGENT.OUT'.
[396] An idle CPU condition has not been defined - OnIdle job schedules will have no effect
[475] Database Mail is not enabled for agent notifications.
[129] SQLSERVERAGENT starting under Windows NT service control

Two lines in there are the ones that fail, and they are the 2 commonest entries in a log where the service did not come up. Both are documented behaviour rather than reproduced here, because provoking them means stopping a running Agent.

• [393] Waiting for SQL Server to recover database 'msdb' as the last line in the file. In the clean start above it is followed within the same second by the rest of the sequence. If it is where the log ends, the Agent is still waiting, and the fault is msdb: offline, suspect, mid-recovery, or restored from a different build and needing an upgrade. The Agent cannot start without it, because every job, schedule and history row lives there. Fix msdb and the Agent starts on its own. If msdb is unavailable because the instance itself will not come up, that is SQL Server Cannot Recover Master (3417), not an Agent problem.
• A failure reading the SQLServerAgent registry key, or no log file written at all. The Agent reads its own configuration from SOFTWARE\Microsoft\MSSQLServer\SQLServerAgent under the instance hive before it can log anything, so when the service account has lost rights to that key the service dies with a Windows service-control error and SQLAGENT.OUT is empty or stale. An empty log after a failed start is therefore a finding, not a dead end: it points at the account, which is the section above. Re-applying the account in Configuration Manager restores the rights, which is the whole reason for preferring it to the Services applet.

The default logging level records errors and warnings only. MS Docs covers raising it and cycling the file under SQL Server Agent Error Log, and it is worth turning up before you reproduce an intermittent startup failure rather than after.

Frequently Asked Questions