Scheduling Background Jobs with a Windows Service in .NET 8

Most line-of-business applications eventually need to run work without a user clicking a button. Whether the job is generating end-of-day reports, syncing records with an external API, or pruning old audit entries, the responsibility for triggering that work tends to drift away from the web tier and onto a process that lives quietly in the background. In Australia, where organisations often span multiple time zones from Perth to Sydney and operate inside strict compliance windows, having a reliable host for those jobs is a practical concern for every engineering team.

.NET 8 makes building that host straightforward. The runtime ships with Microsoft.Extensions.Hosting, a flexible model for long-running processes that play well with dependency injection, configuration, structured logging, and graceful shutdown. By wrapping a background loop inside a BackgroundService, you can produce a Windows-friendly executable that installs as a real operating-system service and recovers automatically if the host machine reboots.

This walkthrough puts those pieces together. It compares a few common scheduling options, then moves step by step through the code, configuration, and operational details for shipping a scheduler as a Windows Service. Along the way, you will see how to keep the service healthy, how to surface failures through logs that Australian IT teams can actually consume, and how to avoid the common pitfalls that turn a tidy background job into a 2 a.m. incident call.

Comparing the Common Scheduling Approaches

Before writing any code, it is worth looking at the choices most .NET shops reach for. Each option has a sweet spot, and the right answer depends on whether the workload already has a host process, whether the schedule is fixed or user-defined, and how much engineering effort is reasonable for the problem at hand.

The table below summarises four practical approaches. They are not mutually exclusive. Many production systems in Brisbane, Melbourne, and Adelaide combine two of them, for example using Hangfire inside an ASP.NET Core app for ad-hoc user jobs while a Windows Service handles nightly batch work.

For predictable, infrastructure-style work that must run whether or not anyone is logged into the server, a Windows Service built on BackgroundService is often the most honest fit. That is the path the rest of this article follows.

Scaffolding the Worker Project

Start with the .NET CLI. A worker template provides the Program.cs and a sample Worker.cs that already implements BackgroundService, which means there is less boilerplate to remove.

dotnet new worker -n AueScheduler -f net8.0
cd AueScheduler
dotnet add package Serilog.Extensions.Hosting
dotnet add package Serilog.Sinks.EventLog

The package Serilog.Sinks.EventLog is convenient in mixed Windows estates. Australian support teams frequently rotate through logs from a central management tool, and writing structured events through the Event Log makes those entries searchable by source. If your servers live in a Microsoft Operations Management ecosystem, the same entries feed straight into forwarded channels with no extra plumbing.

Open Program.cs and switch the generic host into Windows Service mode. Replace the existing builder with the following:

var builder = Host.CreateApplicationBuilder(args);
builder.Services.AddWindowsService(options =>
{
    options.ServiceName = "Aue Scheduler";
});

builder.Logging.ClearProviders();
builder.Logging.AddSimpleConsole();

builder.Services.AddSingleton<IScheduleStore, JsonScheduleStore>();
builder.Services.AddHostedService<SchedulerWorker>();

The UseWindowsService call lives inside AddWindowsService, which only opts in when the executable is run by the Service Control Manager. When the same binary is launched from a developer terminal in Visual Studio, it behaves like a console app. That duality is one of the quiet wins of Microsoft.Extensions.Hosting and a frequent timesaver for teams in North Sydney who need to debug locally without juggling sc start and sc stop between runs.

Add an appsettings.json with sensible defaults. Keep the timezone explicit so that logs are unambiguous when troubleshooting schedules that straddle AEST and AWST.

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.Hosting.Lifecycle": "Information"
    }
  },
  "Schedules": [
    { "Name": "DailySummary", "Cron": "0 6 * * *", "TimeZone": "Australia/Sydney" },
    { "Name": "QuarterlyExport", "Cron": "0 2 1 */3 *", "TimeZone": "Australia/Melbourne" }
  ]
}

Implementing the Background Loop

A scheduler is essentially a loop that wakes up, decides whether any job is due, runs it, and goes back to sleep. The NuGet library Cronos can parse the cron strings above and tell you the next fire time in a nominated zone. Inside SchedulerWorker, the implementation looks roughly like this:

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    var next = DateTimeOffset.UtcNow;
    while (!stoppingToken.IsCancellationRequested)
    {
        var now = DateTimeOffset.UtcNow;
        if (now >= next)
        {
            await RunDueJobsAsync(now, stoppingToken);
            next = ComputeNextFireTime(now);
        }
        await Task.Delay(TimeSpan.FromSeconds(15), stoppingToken);
    }
}

The fifteen-second tick is a compromise. It keeps the service responsive to shutdown signals, including the brief grace period Windows grants before raising the STOP_TIMEOUT after a Stop command. Cancel-aware Task.Delay is the secret sauce. It converts the polite IHostApplicationLifetime stop into actual cooperative cancellation, which means in-flight jobs get a chance to finish rather than being cut off mid-write.

Concurrency deserves a moment. By default, only one job runs at a time. That is fine for many Australian reporting workloads, where the goal is sequential correctness rather than throughput. If parallel execution matters, isolate each job in its own Task and bound the degree of parallelism with a SemaphoreSlim. Be careful with database connections though. A scheduler that opens twenty SQL connections at 6 a.m. will quietly steamroll a tier-two reporting database shared with an in-house finance team in Parramatta.

Errors should never kill the loop. Wrap each job invocation in a try-catch, log the exception with the schedule name as a property, and let the loop continue. A transient outage of an upstream API should never translate into a service that fails to start on the next reboot.

Logging, Deployment, and Day-Two Operations

Logging is where most home-grown schedulers fall down. The default console provider is fine for development, but production Windows Services need Event Log entries that match the conventions of the wider estate. Serilog handles this cleanly:

Log.Logger = new LoggerConfiguration()
    .WriteTo.EventLog("Aue Scheduler", manageEventSource: true)
    .Enrich.WithProperty("Environment", builder.Environment.EnvironmentName)
    .CreateLogger();

Pairing that with structured properties lets you filter by job name, host, or environment inside whatever log aggregator Australian IT standardises on. A common choice across mid-sized enterprises here is the ELK stack, often hosted in AWS Sydney or Azure Australia Central, where keeping data residency onshore matters for federal clients. If the workload touches records covered by the Privacy Act, surfacing the data flow through the same logging pipeline also simplifies the audit trail that security reviewers eventually ask for.

Deployment is a small but important script. Two commands register the executable as a service. Run them elevated, ideally through a DSC configuration or an Ansible role that your platform team already owns:

New-Service -Name "AueScheduler" `
    -BinaryPathName "C:\Services\AueScheduler\AueScheduler.exe" `
    -DisplayName "AUE Background Scheduler" `
    -StartupType Automatic
Start-Service -Name "AueScheduler"

Recovery options matter more than people think. In the Services MMC, set first and second failure actions to Restart the Service with a delay of one minute. That single configuration choice is what protects the schedule from a momentary dip in a downstream endpoint at 6 a.m. Sydney time. For quarterly jobs, also wire the failure cmd to send a Microsoft Teams notification into the on-call channel; the cost of a missed alert is rarely worth the cost of the integration.

Finally, give the schedule itself the same care you give application code. The JSON store is fine for tens of jobs, but the moment a team in your Adelaide office wants hot-reload of cron expressions, promote the store to SQL Server. The same trick that makes Hangfire dashboards work will give your scheduler a manageable surface area when the number of consumers of the schedule grows beyond a single developer.

A well-built BackgroundService Windows Service occupies very little operating expense and pays for itself the first time a quarterly job survives an unattended reboot. That kind of quiet reliability is what production scheduling is really about.