This chapter covers Azure WebJobs, a feature of Azure App Service that allows you to run background tasks in the same context as your web app. WebJobs are a core part of the Compute domain (Objective 1.3) and appear on roughly 5-10% of AZ-204 exam questions, often in scenarios requiring background processing, scheduled tasks, or integration with Azure Storage Queues. You will learn about continuous and triggered WebJobs, their configuration, scaling behavior, and how to deploy and monitor them.
Jump to a section
Imagine a factory assembly line that produces widgets. The factory has two types of workers: permanent employees (continuous WebJobs) who work 24/7 without interruption, and temporary workers (triggered WebJobs) who are called in only when a specific event occurs, like a shipment of raw materials arriving. The factory manager (Azure App Service) ensures that if a permanent worker gets sick or leaves, a replacement is immediately hired to keep the line running. This is like a continuous WebJob that runs on all instances; if one instance fails, another picks up. Temporary workers, however, are only hired for a specific task and leave when done. But there's a catch: the factory has a rule that no temporary worker can work longer than 5 minutes without a break (the 5-minute timeout for triggered WebJobs in Free/Shared tiers). If a temporary worker takes longer, the manager forcibly stops them. For continuous WebJobs, the manager checks every minute that the worker is still active (the Always On feature keeps the app alive). The factory also has a special clock (the CRON schedule) that can be set to call in temporary workers at specific times, like every hour, to clean the machines. The key difference is that permanent workers have a dedicated desk (they run in the same process as the web app), while temporary workers use a shared desk that can be used by others when they leave.
What are Azure WebJobs?
Azure WebJobs are a feature of Azure App Service that enable you to run scripts or programs as background processes within the same App Service plan as your web app. They are designed for tasks that run in the background, such as processing queue messages, running scheduled jobs, or performing maintenance. WebJobs can be triggered by events (e.g., a new message in Azure Queue Storage) or run continuously on all instances of the web app.
Why WebJobs Exist
WebJobs address the need for background processing in a web application without requiring a separate compute service like Azure Functions or a VM. They run in the same sandbox as the web app, which simplifies deployment and management. However, they are limited by the App Service plan's resources and are not suitable for long-running or resource-intensive tasks. The exam tests your ability to choose between WebJobs, Azure Functions, and other compute options.
Types of WebJobs
Continuous WebJobs: Run on all instances of the web app. They execute a program (e.g., a console app) that loops indefinitely, typically listening for messages or performing work. They are automatically started when the web app starts and are restarted if they crash. Continuous WebJobs require the 'Always On' setting to be enabled on the web app; otherwise, the web app may be unloaded after idle time, stopping the WebJob.
Triggered WebJobs: Run on-demand or on a schedule. They are started by an external trigger, such as a manual invocation, a schedule (CRON expression), or an event (like a new blob). They run once and then stop. Triggered WebJobs have a default timeout of 5 minutes in Free/Shared tiers and 230 minutes in Basic/Standard/Isolated tiers. If the job exceeds the timeout, it is killed.
How WebJobs Work Internally
When a WebJob is deployed, Azure App Service stores the files in the site's file system under site/wwwroot/app_data/jobs/continuous or site/wwwroot/app_data/jobs/triggered. The WebJob SDK (or the host runtime) monitors these folders. For continuous WebJobs, the runtime starts the process and keeps it running. If the process exits, it is restarted. For triggered WebJobs, the runtime listens for triggers (e.g., a new queue message) or a schedule, and starts a new process for each trigger. The WebJob runs in a separate process from the web app, but shares the same resources (CPU, memory) of the App Service plan.
Key Components, Values, and Defaults
Always On: Required for continuous WebJobs. Without it, the web app may be unloaded after 20 minutes of inactivity, stopping the WebJob. Always On is not available in Free/Shared tiers.
Timeout: Triggered WebJobs have a timeout of 5 minutes (Free/Shared) or 230 minutes (Basic+). If the job runs longer, it is terminated.
Scale: Continuous WebJobs run on all instances of the web app. Triggered WebJobs run on a single instance, but multiple triggers can run concurrently.
CRON Expression: For scheduled triggered WebJobs, you use a CRON expression in the format {second} {minute} {hour} {day} {month} {day-of-week}. Example: 0 0 2 * * * runs at 2:00 AM daily.
SDK: The WebJobs SDK simplifies writing WebJobs by providing bindings to Azure services (e.g., Queue, Blob, Table). It includes a JobHost that manages the lifecycle.
Configuration and Verification Commands
You can configure WebJobs via the Azure Portal, Azure CLI, or ARM templates. Example Azure CLI to list WebJobs:
az webapp webjob list --resource-group myRG --name myAppTo start a triggered WebJob:
az webapp webjob triggered run --resource-group myRG --name myApp --webjob-name myJobTo set a schedule, you can use the settings.job file in the WebJob folder:
{"schedule": "0 0 2 * * *"}Interaction with Related Technologies
Azure Storage Queues: WebJobs can be triggered by new queue messages. The WebJobs SDK polls the queue and invokes the function when a message arrives.
Azure Blob Storage: Triggered WebJobs can be triggered by new blobs.
Azure App Service: WebJobs run in the same sandbox as the web app. They share the same VM resources.
Azure Functions: A more modern alternative that supports more triggers, better scaling, and a consumption plan. The exam often asks when to use WebJobs vs. Functions: WebJobs are simpler for scenarios where you already have an App Service and need background processing; Functions are better for serverless, event-driven scenarios.
Scaling and Performance
Continuous WebJobs scale with the web app: if you scale out to 5 instances, there will be 5 instances of the WebJob. This can cause contention if the WebJob is not designed to be idempotent. Triggered WebJobs run on a single instance, but you can have multiple concurrent executions. The WebJobs SDK handles singleton behavior using blob leases to ensure only one instance processes a given trigger.
Monitoring and Logging
WebJobs logs are written to site/wwwroot/data/jobs/continuous/{jobName}/job_log.txt and can be streamed via the Azure Portal or CLI. You can also use Application Insights to monitor WebJob performance and failures.
Common Pitfalls
Forgetting to enable 'Always On' for continuous WebJobs.
Using Free/Shared tier for long-running triggered WebJobs (5-minute timeout).
Not handling exceptions in continuous WebJobs, causing them to crash and restart repeatedly.
Scaling out continuous WebJobs without designing for idempotency.
Exam-Relevant Details
The exam may ask about the difference between continuous and triggered WebJobs, the timeout values, and the requirement for Always On.
You may be asked to choose between WebJobs and Azure Functions for a given scenario.
Know that WebJobs can be written in multiple languages: .NET, Node.js, Python, PowerShell, Bash.
WebJobs can be deployed via ZIP, FTP, or Git, and can be managed via the Azure Portal.
The WebJobs SDK is optional but provides convenient bindings.
Deploy WebJob Files
Upload your script or executable to the correct folder under `site/wwwroot/app_data/jobs/continuous/` or `site/wwwroot/app_data/jobs/triggered/`. You can use FTP, Git, or the Azure Portal. Ensure the file is executable (e.g., .exe, .bat, .ps1). For .NET jobs, include all dependencies. The App Service will detect the new files and start the job within a few seconds.
Configure Settings for Triggered Jobs
For triggered WebJobs, you can add a `settings.job` file in the same folder to define a schedule or other settings. The schedule is a CRON expression. Example: `{"schedule": "0 */5 * * * *"}` runs every 5 minutes. The job will run on a single instance. If the job is still running when the next trigger occurs, a new instance may start unless you configure singleton behavior.
Enable Always On for Continuous Jobs
In the Azure Portal, navigate to your App Service -> Configuration -> General Settings. Set 'Always On' to On. This prevents the app from being unloaded after idle time. Without this, continuous WebJobs will stop after 20 minutes of inactivity. Always On is not available in Free/Shared tiers; you must use at least a Basic tier.
Monitor WebJob Health
Use the Azure Portal to view the status of your WebJobs. Under App Service -> WebJobs, you can see if the job is running, stopped, or failed. You can also stream logs using `az webapp log tail` or by downloading the job log file. For continuous WebJobs, the log file is at `data/jobs/continuous/{jobName}/job_log.txt`. Check for exceptions or crashes.
Scale Considerations
When scaling out the App Service plan, continuous WebJobs run on every instance. If your job processes queue messages, use a distributed lock (e.g., blob lease) to ensure only one instance processes a given message. Triggered WebJobs run on a single instance, but multiple triggers can run concurrently. Be aware of resource contention and design accordingly.
Scenario 1: Image Processing Pipeline
A media company uploads images to Azure Blob Storage. A continuous WebJob watches a container for new blobs and resizes them. The WebJob uses the WebJobs SDK with a BlobTrigger attribute. The job runs on all instances; to avoid duplicate processing, it uses a blob lease to ensure each blob is processed once. The company uses a Standard App Service plan with 3 instances. If the job crashes, it restarts automatically. They monitor the job log and set up alerts for failures. A common issue is that the job runs too long for large images, causing timeouts. They moved to a higher tier to increase the timeout from 5 to 230 minutes.
Scenario 2: Scheduled Report Generation
A financial firm needs to generate daily reports at 2 AM. They create a triggered WebJob with a CRON schedule 0 0 2 * * *. The job runs a PowerShell script that queries a SQL database and writes results to a CSV file in Blob Storage. The job runs on a single instance. They use the Basic tier to avoid the 5-minute timeout. A problem arises when the script takes longer than expected due to data growth; they must refactor the script to be more efficient or split the job. They also set up Application Insights to track performance.
Scenario 3: Queue Processing for Order Fulfillment
An e-commerce site uses Azure Queue Storage to queue order processing tasks. A continuous WebJob uses the WebJobs SDK's QueueTrigger to dequeue messages and process orders. The web app is scaled to 5 instances, so there are 5 instances of the WebJob. To prevent multiple instances from processing the same message, the SDK automatically uses a visibility timeout and message dequeue count. They set the queue's visibility timeout to 30 seconds. A misconfiguration caused messages to be processed multiple times because the job took longer than the visibility timeout; they increased the timeout to 5 minutes.
What AZ-204 Tests on WebJobs
Objective 1.3 includes implementing background tasks using WebJobs. Key areas:
Differences between continuous and triggered WebJobs.
Requirement for 'Always On' for continuous WebJobs.
Timeout values: 5 minutes (Free/Shared) vs 230 minutes (Basic+).
How to schedule triggered WebJobs using CRON expressions in settings.job.
Deployment methods and file locations.
Scaling behavior: continuous run on all instances; triggered run on one instance.
When to choose WebJobs over Azure Functions.
Common Wrong Answers
'WebJobs run in a separate App Service plan' – Wrong. WebJobs run in the same plan as the web app. They share resources.
'Triggered WebJobs require Always On' – Wrong. Only continuous WebJobs require Always On. Triggered WebJobs can run even if the app is idle because the trigger wakes the app.
'WebJobs support all triggers like Azure Functions' – Wrong. WebJobs natively support only a few triggers (Queue, Blob, etc.) without custom code. Azure Functions has more triggers.
'Continuous WebJobs run on a single instance' – Wrong. They run on all instances. This is a key distinction.
Specific Exam Numbers
Always On setting: must be enabled for continuous WebJobs.
Timeout for triggered WebJobs: 5 minutes (Free/Shared), 230 minutes (Basic+).
CRON format: {second} {minute} {hour} {day} {month} {day-of-week}.
File path: site/wwwroot/app_data/jobs/continuous/ or site/wwwroot/app_data/jobs/triggered/.
Edge Cases
If you run a triggered WebJob on a Free tier and it exceeds 5 minutes, it is killed. The exam may present a scenario where a job fails mysteriously; the answer is the timeout.
If you scale out a continuous WebJob that is not idempotent, you may get duplicate processing. The exam may ask how to prevent this: use blob leases or singleton mode.
WebJobs can be written in multiple languages: .NET, Node.js, Python, etc. The exam may ask which languages are supported.
How to Eliminate Wrong Answers
If the question mentions a background task that needs to run on a schedule and you already have an App Service, WebJobs are a good fit. If the task is event-driven and needs to scale independently, consider Azure Functions.
If the question says 'must run continuously' and 'Always On' is not mentioned, the answer is likely Azure Functions (consumption plan) because WebJobs require Always On.
If the question mentions a timeout of 5 minutes, the answer is likely triggered WebJobs on Free/Shared tier.
Continuous WebJobs run on all instances and require Always On to stay active.
Triggered WebJobs have a timeout of 5 minutes (Free/Shared) or 230 minutes (Basic+).
WebJobs are stored in `site/wwwroot/app_data/jobs/continuous/` or `triggered/`.
Scheduled triggered WebJobs use a CRON expression in a `settings.job` file.
WebJobs share the same App Service plan resources as the web app.
WebJobs can be written in .NET, Node.js, Python, PowerShell, or Bash.
For event-driven scenarios with more triggers, Azure Functions is preferred over WebJobs.
These come up on the exam all the time. Here's how to tell them apart.
Continuous WebJobs
Runs continuously on all instances
Requires Always On setting enabled
Automatically restarted if crashes
Suitable for long-running background tasks
Shares resources with web app on each instance
Triggered WebJobs
Runs on-demand or on a schedule
Does not require Always On
Runs once per trigger, then stops
Has a timeout (5 or 230 minutes)
Runs on a single instance
Mistake
WebJobs run in a separate process from the web app, so they don't share resources.
Correct
WebJobs run in the same sandbox and share CPU, memory, and network resources of the App Service plan. They can affect the web app's performance.
Mistake
Triggered WebJobs can run indefinitely without timeout.
Correct
Triggered WebJobs have a timeout of 5 minutes in Free/Shared tiers and 230 minutes in Basic+ tiers. If they exceed this, they are terminated.
Mistake
Continuous WebJobs automatically scale down when the app is idle.
Correct
Continuous WebJobs require Always On to prevent the app from being unloaded. Without Always On, the app and WebJob stop after 20 minutes of inactivity.
Mistake
WebJobs can be triggered by HTTP requests like Azure Functions.
Correct
WebJobs do not have an HTTP trigger. They are triggered by schedules, queues, blobs, or manual invocation. For HTTP triggers, use Azure Functions.
Mistake
All WebJobs run on all instances of the App Service.
Correct
Only continuous WebJobs run on all instances. Triggered WebJobs run on a single instance, but multiple triggers can run concurrently on that instance.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Continuous WebJobs run indefinitely on all instances of the App Service and are automatically restarted if they crash. They require the Always On setting. Triggered WebJobs run once per trigger (e.g., schedule or queue message) and stop after completion. They have a timeout and run on a single instance. Choose continuous for long-running tasks that need high availability, and triggered for short, event-driven tasks.
No. Triggered WebJobs do not require Always On because they are started by an external trigger (e.g., a schedule or queue message). The trigger wakes the app if it is idle. However, if you have a continuous WebJob, you must enable Always On to keep the app running.
The default timeout depends on the App Service plan tier: 5 minutes for Free/Shared tiers, and 230 minutes for Basic, Standard, and Isolated tiers. If the job runs longer, it is terminated. You can configure a custom timeout using the `WEBJOBS_IDLE_TIMEOUT` setting, but it cannot exceed the tier limit.
Create a `settings.job` file in the WebJob folder (e.g., `site/wwwroot/app_data/jobs/triggered/myJob/settings.job`) with a JSON object containing a `schedule` property. The schedule is a CRON expression in the format `{second} {minute} {hour} {day} {month} {day-of-week}`. Example: `{"schedule": "0 0 2 * * *"}` runs daily at 2:00 AM.
No. WebJobs run within the same App Service instance as the web app. They are not a separate service. If you need geo-distributed background processing, consider Azure Functions or a separate App Service in another region.
Use a distributed lock mechanism like blob leases or the Singleton attribute in the WebJobs SDK. The Singleton attribute ensures that only one instance of the job processes a given trigger (e.g., queue message) at a time. Alternatively, design your job to be idempotent.
WebJobs support any language that can run on Windows or Linux App Service. Common languages include .NET (C#, VB), Node.js, Python, PowerShell, and Bash scripts. The executable or script file must be placed in the appropriate folder.
You've just covered Azure WebJobs and Continuous Jobs — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?