Coming Soon: GET-IT: Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET Coming Soon: GET-IT: Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET
Microsoft Azure

Adding WebJobs to Azure App Service

In this post, I will explain how you can use WebJobs to execute tasks on Azure App Service.


The Requirement

You might require some sort of task to run in Azure, for example, when I upload an image via a Web App, a background task will pick up that image, do something to it, and then email me a link to download the results.

Sponsored Content

Say Goodbye to Traditional PC Lifecycle Management

Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.

This sort of task was historically done by a WebJob, a task that could execute in the abstracted virtual machine environment of Azure App Services. A WebJob, in short, is some script or executable that can be run continuously, manually started, or triggered on a scheduled basis.

Functions as an Alternative

WebJobs run in Azure App Service plans. There are two considerations, especially for larger applications:

  • Performance and Cost: When you have a large-scale mobile or web application, it is recommended that any WebJobs are placed into a different App Service plan (pool of abstracted virtual machines), giving you the ability to scale the background tier separately from the web tier and giving the web tier its own processor/memory capacity. This means that you will have an additional fixed cost for each virtual machine instance in the additional App Service plan(s).
  • Scale-Out: You can auto-scale an App Service plan. This is very fast but it will reach a limit. And, there is a large increment in the cost (per-minute charge for the App Service instance).


Azure Functions are similar to WebJobs because they allow you to perform some task in the background. Functions are triggered by a schedule or event; in other words, an instance of the Function is instantiated by Azure in response to something happening to perform a task. When that task is completed, the instance disappears. There is no server, so there is no big incremental cost; instead you pay for each second of Function run time. On the plus side, smaller tasks should reduce your Azure costs and Functions can scale beyond the limitations of your App Service plans. On the downside, there is a potential for a huge bill if your Functions go wild. Azure App Service plans have a fixed/predictable per-instance (virtual machine) cost.

Functions currently support C#, JavaScript, and F# with another of other languages and scripting environments in an experimental stage. WebJobs however, support a number of scripting languages and .CMD, .BAT, and compiled executables:

  • .cmd, .bat, .exe (using Windows cmd)
  • .ps1 (using PowerShell)
  • .sh (using Bash)
  • .php (using PHP)
  • .py (using Python)
  • .js (using Node.js)
  • .jar (using Java)

So while Functions are hot right now, WebJobs still have an important role to play, especially when one is migrating existing applications to Azure.

Creating a WebJob

This process is quite simple. Create a new Web App, which is confusingly called an App Service in the Azure Portal. Open the App Service and open Settings > WebJobs.

Click + Add and a Add WebJob blade will appear. Enter the following information:

  • Name: Give the WebJob a name to identify it.
  • File Upload: Click the folder button, and browse to and select the script or executable that you will be using. This file will be uploaded to your App Service.
  • Type: Choose Continuous or Triggered.

If you selected Continuous you have two options for Scale:

  • Multi Instance: The task will run on all instances (virtual machines) of the App Service plan.
  • Single Instance: The App Service plan will ensure that the task is running on just one instance (virtual machine).

If you select Triggered, then you can choose between:

  • Scheduled: You must enter a CRON expression for the schedule.
  • Manual: It will be the responsibility of an operator to start the task.


Note that you must ensure that Always On is enabled in the Application Settings of the Web App before adding a continuous or scheduled WebJob.

A new Azure App Service WebJob that will run an executable every day at 21:00 [Image Credit: Aidan Finn]
A New Azure App Service WebJob that Will Run an Executable Every Day at 21:00 [Image Credit: Aidan Finn]
Click OK, your script/executable will be uploaded, and the WebJob will be created.

A new Azure App Service WebJob [Image Credit: Aidan Finn]
A New Azure App Service WebJob [Image Credit: Aidan Finn]

Related Topics:


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (0)

Leave a Reply

Aidan Finn, Microsoft Most Valuable Professional (MVP), has been working in IT since 1996. He has worked as a consultant and administrator for the likes of Innofactor Norway, Amdahl DMR, Fujitsu, Barclays and Hypo Real Estate Bank International where he dealt with large and complex IT infrastructures and MicroWarehouse Ltd. where he worked with Microsoft partners in the small/medium business space.
Live Webinar: Active Directory Security: What Needs Immediate Priority!Live on Tuesday, October 12th at 1 PM ET

Attacks on Active Directory are at an all-time high. Companies that are not taking heed are being punished, both monetarily and with loss of production.

In this webinar, you will learn:

  • How to prioritize vulnerability management
  • What attackers are leveraging to breach organizations
  • Where Active Directory security needs immediate attention
  • Overall strategy to secure your environment and keep it secured

Sponsored by: