Where Did My SQL Agent Go? Scheduling Jobs in Azure SQL Database

I have been doing SQL Server work for over twenty years. In that time, SQL Agent became as fundamental to my work as SSMS itself. The moment I inherit a new environment, I pull up the Agent jobs. That job list tells me everything — how disciplined the team is, what kind of maintenance actually runs, whether anyone thought about operationalizing the environment or just bolted a database to the wall and hoped for the best.

So the first time I deployed a workload to Azure SQL Database and went looking for the Agent, I had the same reaction most senior DBAs have.

Where the heck did it go?

The short answer: it was never there. Azure SQL Database is a PaaS offering. Microsoft manages the hardware, OS, patching, HA, and backups. You get the database engine — not the instance. SQL Agent is an instance-level service. No instance, no Agent.

Once you internalize that mental model, the frustration fades and the real question emerges: what do I use instead?

Let me walk you through your options — not from a marketing brochure perspective, but from the perspective of someone who has actually had to keep production workloads running in the cloud.

---

What We're Actually Trying to Replace

Before we talk solutions, let's be honest about what SQL Agent actually does in most shops. The typical Agent job list looks something like this:

• Index rebuilds and reorganizations
• Statistics updates
• Integrity checks (DBCC CHECKDB)
• Backup jobs (full, differential, log)
• ETL processes — data loads, transforms, report staging
• Cleanup routines — purging history tables, archiving old records
• Monitoring and alerting — custom health checks, threshold notifications
• Business process automation — end-of-day processing, batch jobs, file imports

In Azure SQL Database, Microsoft takes ownership of backups, HA, and patching. That removes a chunk of the Agent job list right there. But the ETL processes, the cleanup routines, the business logic batch jobs — those are still your responsibility. You just need a different mechanism to run them.

Here is what you have available.

---

Option 1: Azure Elastic Jobs

This is the closest thing Azure provides to a native SQL Agent replacement for Azure SQL Database.

Azure Elastic Jobs lets you schedule T-SQL execution against one or more Azure SQL databases. You define a job, add steps, set a schedule, and it runs. For DBAs migrating from SQL Agent with T-SQL-heavy job steps, this will feel the most familiar.

Where Elastic Jobs particularly shines is multi-database scenarios. If you are running a multi-tenant SaaS architecture with dozens or hundreds of tenant databases, Elastic Jobs can fan out a single job execution across all of them simultaneously. That capability alone is something SQL Agent never had natively.

Setup is a bit involved. You need an Elastic Job Agent resource, a dedicated job database, and proper credential configuration. It is not as turnkey as right-clicking in SSMS. But once it is running, it is solid.

Best for: Scheduled T-SQL execution, stored procedure calls, index maintenance scripts, multi-database fan-out operations.

Watch out for: The setup overhead. If you just need to call one stored procedure on a schedule, this might be more infrastructure than the job warrants.

---

Option 2: Azure Automation with Runbooks

This is where I land most often when working with clients on Azure SQL Database environments, and it is what I default to when I have flexibility.

Azure Automation runs Runbooks — scripts written in PowerShell or Python — on a schedule. For a DBA, a PowerShell Runbook that calls Invoke-Sqlcmd to execute a stored procedure is trivially easy to build and maintain. But the real power is what you can do around the SQL call.

A Runbook can:

• Query Azure SQL Database
• Parse the results and make decisions
• Send email or Teams notifications based on outcomes
• Write logs to a storage account
• Call other Azure services
• Execute against multiple databases in sequence
• Handle errors and retry logic gracefully

Compare that to SQL Agent, where your alerting options were limited to Database Mail and the notification tab. Azure Automation gives you a full scripting environment with access to the entire Azure ecosystem.

Hybrid Worker is worth calling out here. If you have on-premises servers or Azure VMs that need to participate in your automation, the Hybrid Runbook Worker feature lets you run Automation jobs on your own machines. This is useful for workloads that need local file system access or connectivity to resources not exposed over public endpoints.

Best for: DBA automation, monitoring jobs, health checks, scenarios where you need logic beyond "run this T-SQL," hybrid environments.

Watch out for: PowerShell runbooks require someone comfortable with PowerShell. If your team is T-SQL-only, there is a learning curve.

---

Option 3: Azure Functions with Timer Triggers

Azure Functions are serverless compute — code that runs in response to a trigger. The Timer Trigger uses a cron expression to fire on a schedule, which makes it a legitimate scheduling option.

The difference between Functions and the other options is the programming model. Functions are written in C#, JavaScript, Python, Java, or PowerShell. They are stateless, event-driven, and designed for short-duration tasks.

For a database team, this option makes the most sense when the scheduled work is already part of an application codebase. If your dev team owns the code, Azure Functions fits naturally. If it is DBA-owned operational work, the overhead of managing a Function App for something that used to be three lines in a job step can feel excessive.

Functions do have a consumption-based pricing model, so for very high-frequency schedules, you will want to do the math on cost.

Best for: Application-owned scheduled logic, event-driven processing, developer-led teams, scenarios where you need the full power of a programming language.

Watch out for: Cold start latency on consumption plans, not the right fit for pure DBA operational tasks.

---

Option 4: Logic Apps

Logic Apps are Microsoft's low-code workflow automation platform. If you are familiar with Power Automate, Logic Apps is the enterprise-grade cousin.

For a DBA, the use cases tend to be at the boundary between the database and other systems: sending a report email when a daily process completes, kicking off a pipeline when a file lands in Blob Storage, triggering a notification when a row count exceeds a threshold.

Logic Apps are excellent for orchestrating multi-step business workflows. They have connectors for hundreds of services. For pure database scheduling work, they are probably overkill. But for the jobs that are as much business process as they are database work, Logic Apps can replace what used to be a fragile combination of SQL Agent, Database Mail, and manual hand-offs.

Best for: Business process automation, workflows involving multiple systems, notification-heavy processes, scenarios where a non-technical user needs to own or modify the workflow.

Watch out for: Cost at scale — Logic Apps pricing is consumption-based and can add up for high-volume workflows.

---

Option 5: Use SQL Agent From a Hybrid Server

I want to spend a moment on this one because it gets dismissed too quickly.

Many organizations running Azure SQL Database are not running in a pure cloud environment. They have on-premises servers, Azure VMs, or utility servers of some kind. SQL Server is almost certainly running somewhere — a monitoring server, a DBA tools server, a jump box with SQL Server Developer Edition on it.

There is absolutely nothing wrong with keeping a SQL Agent instance running on one of those servers and pointing job steps at Azure SQL Database via a linked server or a direct connection string. The job runs on-premises, the execution happens in Azure, and you get all the familiar SQL Agent tooling you have used for years.

For smaller environments or shops in the early stages of cloud adoption, this is often the pragmatic choice. You get Azure SQL Database's managed benefits while keeping your operational tooling stable.

Best for: Hybrid environments, smaller teams, shops that want cloud databases without immediately rebuilding their entire operations model.

Watch out for: The on-premises server becomes a dependency. If it goes down, so do your scheduled jobs. For critical workloads, that is a risk to evaluate.

---

How to Choose

Here is the decision framework I use with clients:

| Scenario | My Recommendation |

|---|---|

| Pure T-SQL, single or multi-database | Azure Elastic Jobs |

| DBA-owned operational automation | Azure Automation |

| App-owned scheduled logic | Azure Functions |

| Business process / multi-system workflows | Logic Apps |

| Hybrid environment, existing SQL Agent server available | Keep SQL Agent |

The honest truth is that for most mid-size environments, you will end up using more than one of these. Your ETL process goes into Elastic Jobs. Your health check monitoring goes into Azure Automation. Your report distribution workflow goes into Logic Apps. SQL Agent in a single environment often did three or four conceptually different things — in Azure, you align each concern with the service that fits it best.

---

The Mindset Shift

The part that trips up experienced SQL Server DBAs is not the technology — it is the mental model.

On-premises SQL Server, you manage a server. You own the operating system, the service, the Agent, the filesystem. Everything lives under one roof.

Azure SQL Database, you manage a service. The server is Microsoft's problem. Your job is to configure, connect, and operate the database tier — and wire it into Azure's broader service ecosystem when you need platform capabilities like scheduling.

That shift feels like a loss of control at first. After a few months working this way, most DBAs I know come around. Not having to worry about patching, storage, HA failover configuration, or Agent service restarts after an OS update quietly frees up a surprising amount of mental overhead.

The SQL Agent is not missing. You are just working at a different layer of the stack now.

---

Practical Starting Point

If you are just getting started with Azure SQL Database scheduling, here is what I suggest:

1. Audit your SQL Agent jobs before the migration. Categorize each one: pure T-SQL, PowerShell/scripting, business workflow, or maintenance.

2. Let Azure handle what Azure handles. Backups and HA are gone from your job list automatically.

3. Pick one non-critical job and migrate it to Azure Automation first. Get comfortable with Runbooks, logging, and alerting before you move anything business-critical.

4. Evaluate Elastic Jobs if you have multi-database scenarios or want to stay close to a T-SQL-native experience.

5. Keep SQL Agent in your hybrid environment if that is where you are today. You do not have to migrate everything at once.

The goal is not to replicate SQL Agent in the cloud. The goal is to keep your scheduled workloads running reliably — using the right tool for each type of work.