App Service WebJobs overview

Azure WebJobs is a built-in feature of Azure App Service that enables you to run background tasks, scripts, and programs alongside your web, API, or mobile applications. WebJobs simplify automation for common operations by running in the same scalable, managed environment as your application. Common operations include data processing, image resizing, queue handling, and file cleanup.

Choosing WebJobs

WebJobs are a good fit when:

• You already host your application on App Service.
• You want to deploy and manage background tasks together with your app.
• You don't require a separate scaling model or event-based triggers beyond basic scheduling or queue polling.

For more scalable, independently hosted, or event-driven workloads, consider using Azure Functions.

Key capabilities

• Run background tasks without provisioning separate infrastructure
• Trigger jobs on demand, on a schedule, or continuously
• Use multiple languages and scripting platforms
• Deploy using the Azure portal, Visual Studio, zip deployment, or automation pipelines
• Monitor and troubleshoot using Kudu or App Service diagnostics
• Integrate with other Azure services such as Azure Storage, Event Hubs, or Service Bus

WebJob types

WebJobs come in three main types:

• Triggered WebJobs: Run on demand or in response to specific events. You can trigger them manually or from a service like Azure Storage.
• Scheduled WebJobs: A specialized type of triggered WebJob that runs on a defined schedule using a settings.job file with NCRONTAB expressions.
• Continuous WebJobs: Run persistently in the background while your App Service app runs. Ideal for queue polling or background monitoring tasks.

Supported platforms and file types

WebJobs are supported on the following App Service hosting options:

• Windows code
• Windows containers
• Linux code
• Linux containers

Supported file/script types include:

• Windows executables and scripts: .exe, .cmd, .bat
• PowerShell scripts: .ps1
• Bash scripts: .sh
• Scripting languages: Python (.py), Node.js (.js), PHP (.php), F# (.fsx), Java (.jar, .war)
• Any language runtime included in your container app

This versatility enables you to integrate WebJobs into a wide range of application architectures using the tools and languages you're already comfortable with.

Deployment options

You can deploy WebJobs using several methods:

• The Azure portal or zip upload: Manually upload your script or job files.
• Visual Studio: Deploy directly with your ASP.NET app to Windows App Service.
• CI/CD pipelines: Automate deployment with GitHub Actions, Azure Pipelines, or Azure CLI.
• ARM/Bicep templates: Deploy infrastructure and jobs declaratively.

WebJobs also provide built-in logging by using Kudu and integration with App Service diagnostics to help you monitor job activity and troubleshoot issues.

Scaling considerations

WebJobs scale together with your App Service plan. If your app is configured to scale out to multiple instances, your WebJobs run on each instance as appropriate:

• Triggered WebJobs runs on a single instance by default.
• Continuous WebJobs can be configured to run on all instances or a single one using the WEBJOBS_RUN_ONCE setting.

If you need independently scalable or event-driven execution, Azure Functions might be more appropriate.

Best practices

• Use triggered WebJobs for improvised or scheduled operations.
• Use continuous WebJobs only when the task needs to run constantly, such as polling a queue.
• Implement retry logic and error handling in your scripts.
• Use application logging and Kudu logs to monitor job behavior.
• Keep job logic separate from main app logic when possible.
• Use storage-based triggers, such as Azure Queues, for reliable, decoupled communication.

Choose your scenario

Related content

• Review background jobs best practices
• Develop and deploy WebJobs using Visual Studio
• Get started with the WebJobs SDK
• Use the WebJobs SDK for background processing
• Review Kudu WebJobs reference on GitHub