Pitfalls of Hosting Background Workers as Azure App Service

Pitfalls of Hosting Background Workers as Azure App Service

02 Mar 2024

I hope you had a better day than me...

I spent my day looking at this:

ERROR - Container backgroundworker_x didn't respond to HTTP pings on port: 8080, failing site start.

What is that supposed to be?

  • A .NET 8 background worker service hosted on an Azure App Service (Linux container).
  • Should run only once every 24 hours.
  • Has "Always on" (waste).
  • Has "Health checks off".

What's wrong?

  • It recycles every 10 minutes due to supposed error.
  • It suddenly restarts and interrupts any ongoing work.

What rabbit holes did I look into?

  • Exposing that port, extending amount of time to start, ... (not the problem)
  • Investigating health checks. (shouldn't be the problem)
  • Investigating alternatives like WebJobs (for Windows container), ...
  • ...

I slightly panicked when I wondered if this behavior was also happening on my other App Services that host APIs or Blazor apps. These do idle after a while of inactivity but sudden restarts wouldn't be great.

Why are those not facing the same issue? Well, these are webapps "initialized successfully and is ready to serve requests"

So my simple, hacky solution is to convert my background worker services into web projects by changing the Sdk="Microsoft.NET.Sdk.Worker" to Sdk="Microsoft.NET.Sdk.Web" and slightly modify the "Progam.cs". And, I added a health check endpoint just in case.

The WebJobs approach might have been better but not available on my Linux App Service.

Azure Functions but has been quite a struggle so far.

Do you know better ways to host Background Worker Services and run them (CRON) periodically? Let me know!


Join the community

I continuously build, learn and experiment with innovative technology. Allow me to share what I learn, with you.

Newsletter

Allow me to share what I learn, with you.

Share

Support

An error has occurred. 🗙