SQL Agent

✓ functional

Browse jobs, history, schedules, operators, and alerts from msdb, with script-first job control.

The SQL Agent browser surfaces the instance's automation from msdb in real grids: Jobs, History, Schedules, Operators, and Alerts, each on its own tab. Some columns are computed for you client-side: the Schedules tab decodes sysschedules' frequency encoding into a human-readable recurrence and a predicted next run, and the Alerts tab turns message id and severity into a plain condition column.

It is more than a viewer. Jobs, schedules, alerts, and operators each have Create… and Edit Selected…, which swap the grid for an inline form - job name, owner, step subsystem and command, schedule frequency and start time, alert message id or severity, operator email - with a live SQL preview that updates as you type and turns to a warning when a field will not validate. The Jobs tab adds Script Start, Script Stop, and a state-aware Script Enable / Disable toggle that follows the selected job.

Script-first job control. Nothing runs from the dialog. Every action - including create and edit - opens the reviewed sp_add_job / sp_update_job / sp_start_job SQL in a query tab, headed by a comment noting it needs an msdb SQLAgent role (or sysadmin), so you decide, in context, whether to run it - the same contract every write path in SQLly follows.

SQLly SQL Agent jobs browser — SQL Agent: the Jobs tab with a job grid, and script-first Start / Stop / Enable / Delete actions in the footer.

SQL Server only - the Agent and msdb are a SQL Server concept. The dialog probes for the Agent when it opens, and says so honestly when it is absent: Azure SQL Database has no Agent (use Elastic Jobs there), while SQL Server and Azure SQL Managed Instance expose it normally.