Retrace now supports Azure WebJobs

How to Monitor Azure WebJobs: Performance, Errors, Usage

Matt Watson Developer Tips, Tricks & Resources Leave a Comment

Azure Cloud Services and App Service made it relatively easy to run web applications in the cloud. Developers still need a simple way to run tasks on a schedule at pre-defined  times or specific intervals . We commonly use simple console apps via the Windows Task Scheduler to handle these needs. WebJobs were released as part of Azure App Service to run background jobs and perfectly solve the need for running applications continuously like a Windows service, or on a schedule like normal Windows scheduled tasks.

Why monitoring WebJobs is different?

Monitoring Azure WebJobs, Windows Services and similar background services are much different than monitoring web applications. Web applications have very defined “transactions” based on each web request. It is very simple for services like Retrace to identify each individual web request and track the performance of them.

Console applications and background services have no defined start or end to the work that they do. They can start and run continuously or run for just a few milliseconds on a periodic schedule. To properly monitor your Azure WebJobs, you need to define the start and end of the transactions or operations they are performing.

You should also consider using Azure Functions. Compare Azure Functions vs Azure Web Jobs.

Identifying “operations” in your WebJobs

WebJobs and other background services usually follow several common patterns. By identifying these patterns, you can quickly evaluate the best way to identify operations in your code.

Think of an operation as a unit of work that often are repeated over and over. You need to identify them and then potentially monitor each different operation.

These are common usage patterns:

  • Simple task – Some apps start, do something, and immediately stop. The entire scope of their execution is an operation. Most triggered applications are simple tasks, or groups of simple tasks.
  • Queue listener – App continuously listens on a queue and each message processed from a queue would be a unique operation.
  • Timer-based – Many apps start and run continuously. They may use timers in their code to repeat a specific operation periodically like polling a database.Since WebJobs support triggered schedules, this type might not as common as it would be in a Windows service.
  • Job scheduler – It is possible to embed a job scheduler like Quartz.NET within your WebJob to trigger small jobs. Since WebJobs support triggered schedules, this type might not as common as it would be in a Windows service.

Most WebJobs are likely to perform multiple operations. I would suggest breaking them down to the smallest logical units of work. It is better if you monitor smaller units of work. This is similar to monitoring each web request in your ASP.NET web application versus monitoring the performance of the application as a whole.

For example, I have an app that gets a list of things to do from a database and then processes them in a loop. I would define the work that it does within the loop as the operation. This allows you to track how many times it happens and how long it takes each time.

As another example, I have a console application that runs every 15 minutes and does several different things. Each one of those things, should be a separate operation.

How to instrument “operations” in your code for Retrace

Once you have identified the operations you would like to track, you will need to make a few minor code changes. Retrace relies on using the open source StackifyLib NuGet package for sending errors, logs, and custom metrics to Stackify for defining the operations in your code. Basically, you just wrap your code with an object and give it a name. Retrace’s .NET profiler uses this to track these segments of your code as logical operations within your WebJob.

Example of instrumenting your code for Retrace:

For more information and code examples, please see our docs about using Retrace for tracking non-web transactions.

How to install Retrace for Azure WebJobs

Retrace is installed as a site extension for your Azure App Service. With the Azure Portal, simply select your App Service, go to extensions and find the Stackify site extension and install it. You will also need to set some application settings in the Azure Portal for your application, including your Stackify ApiKey.

For more details on how to install Retrace for WebJobs, please consult our docs.

Benefits of monitoring Azure WebJobs with Retrace

Once your code has been instrumented and Retrace is collecting data about your WebJob, you can get some amazing details about what your code is doing.

Retrace automatically supports most common .NET dependencies and frameworks with no code changes. You can instantly see how they are being used by your application and how they impact performance. This includes SQL Server, external web services, MongoDB, Elasticsearch, Redis, Azure PaaS services, and much more.

Identifying top operations

Retrace allows you to see all the operations being executed by your code. Quickly identify how often each of them are executed, average run time, and much more. Most developers suffer from “they don’t know what they don’t know” when it comes to the performance of their applications. Retrace provides instant visibility so you don’t have to rely on your spidey senses.

monitor azure webjobs top operations

Tracking top SQL queries

Retrace automatically tracks every SQL query executed by your code. Quickly identify which queries are being executed, how long they take, and how often they are being called.


View application exceptions & logs

Since Retrace works via lightweight code profiling, it also has the ability to collect all exceptions being thrown by your code. This include all first chance exceptions being thrown by your code or just exceptions being logged to your logging frameworks.

Retrace provides powerful error monitoring and log management features. You can send all of your logging to Retrace via NLog, log4net, Serilog, and others. With Retrace you can search across all of your logs from one place and do many other advanced log management features.

View code-level traces

One of the most powerful features of Retrace is the code-level snapshots that it collects. For any of the operations being tracked for your WebJob, you can view all of the key methods, dependencies being called, exceptions, logs, and much more in context.

Example trace from a WebJob:


Retrace vs Application Insights for WebJobs

There are many differences between Stackify Retrace and Azure Application Insights. The most important one in regards to WebJobs is that Application Insights doesn’t really support WebJobs out of the box. It requires manually coding everything in your application that you want to send it.

With Retrace, all you have to do is define the operations within your code and all application dependencies, exceptions, and logs are then tracked. Retrace just works.

Application Insights requires that you manually report to them every single dependency call. This means every single place you do a SQL Database, web service call, or similar dependency usage, you would have to modify your code to report it. Sounds like fun, right?

Retrace is an excellent choice for Azure WebJobs, Windows services or Azure worker roles.


Azure WebJobs enable developers to run a wide array of background services on the Azure cloud. They are a very simple and powerful feature that virtually all developers need. Monitoring the performance of those applications is also important.

Retrace is an excellent solution for monitoring the performance of your Azure WebJobs. Retrace works with all ASP.NET, .NET Core, and .NET applications.

To learn more, check out our product page about Retrace, our Azure monitoring guide, and our overview of application monitoring.

About Matt Watson

Matt is the Founder & CEO of Stackify. He has been a developer/hacker for over 15 years and loves solving hard problems with code. While working in IT management he realized how much of his time was wasted trying to put out production fires without the right tools. He founded Stackify in 2012 to create an easy to use set of tools for developers.