Using IHostedService for recurring HTTP calls in .NET

Many .NET applications need to contact an external endpoint on a schedule. A service might refresh exchange rates, collect telemetry, synchronise customer records, poll a payment provider, or check the status of a long-running job. Running that work from a controller request is unreliable because it ties background processing to a user’s connection and application traffic.

IHostedService provides a lifecycle-aware way to run recurring HTTP operations inside an ASP.NET Core application or another .NET host. It starts with the application, receives cancellation when the process shuts down, and can share the dependency injection, configuration, logging, and health-check infrastructure already used by the application.

How hosted services fit into the .NET host

An implementation of IHostedService has two central methods: StartAsync and StopAsync. The host calls them when the application starts and stops. The service should use StartAsync to initialise its background operation, rather than keeping the host startup thread busy with an endless loop.

BackgroundService is an abstract base class that implements IHostedService and provides an ExecuteAsync method for the long-running task. It is generally the simplest choice for recurring HTTP calls. The host supplies a cancellation token, so the worker can stop promptly during deployment, a container restart, or a controlled shutdown.

public sealed class PartnerPollingService : BackgroundService
{
    protected override Task ExecuteAsync(CancellationToken stoppingToken)
    {
        return Task.CompletedTask;
    }
}

Register the worker with dependency injection so the generic host can manage it:

builder.Services.AddHostedService<PartnerPollingService>();

A hosted service is usually registered as a singleton. That means its constructor should receive long-lived dependencies such as IHttpClientFactory, configuration options, and logging. A scoped dependency, such as an Entity Framework Core DbContext, should be resolved inside a scope created for each iteration.

Selecting an interval and execution model

A recurring worker needs a clear definition of its schedule. “Every five minutes” can mean five minutes after the previous request finishes, or at fixed clock intervals regardless of request duration. For external HTTP calls, waiting until the previous operation completes before starting the next one is generally safer. It avoids overlapping requests when a partner API becomes slow.

PeriodicTimer is a useful modern .NET option because it works naturally with asynchronous code and cancellation. The first request can run immediately, followed by the configured delay, or the worker can wait for the first tick if an initial delay is preferable.

private readonly TimeSpan _interval = TimeSpan.FromMinutes(5);

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    using var timer = new PeriodicTimer(_interval);

    while (await timer.WaitForNextTickAsync(stoppingToken))
    {
        await PollPartnerAsync(stoppingToken);
    }
}

This approach is preferable to Thread.Sleep, which blocks a thread, and usually clearer than a System.Threading.Timer callback that can make asynchronous exception and overlap handling more complicated. The interval should live in configuration rather than being hard-coded, especially when Australian customers operate across AEST and AEDT or when a partner imposes different limits during local business hours.

Building a safe HTTP polling worker

Use IHttpClientFactory rather than constructing HttpClient repeatedly inside the loop. The factory manages handler lifetimes and connection reuse, helping avoid socket exhaustion and stale DNS information. A named or typed client also gives the external integration a clear place for its base address, headers, timeout, and resilience policy.

public sealed class PartnerPollingService : BackgroundService
{
    private readonly IHttpClientFactory _clientFactory;
    private readonly ILogger<PartnerPollingService> _logger;

    public PartnerPollingService(
        IHttpClientFactory clientFactory,
        ILogger<PartnerPollingService> logger)
    {
        _clientFactory = clientFactory;
        _logger = logger;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        using var timer = new PeriodicTimer(TimeSpan.FromMinutes(5));

        while (await timer.WaitForNextTickAsync(stoppingToken))
        {
            try
            {
                var client = _clientFactory.CreateClient("PartnerApi");
                using var response = await client.GetAsync(
                    "/status",
                    stoppingToken);

                response.EnsureSuccessStatusCode();
                _logger.LogInformation("Partner status retrieved");
            }
            catch (OperationCanceledException) when (stoppingToken.IsCancellationRequested)
            {
                break;
            }
            catch (HttpRequestException ex)
            {
                _logger.LogWarning(ex, "Partner status request failed");
            }
        }
    }
}

The cancellation exception is treated differently from a network failure. Cancellation during shutdown is expected and should not create alarming error logs. A genuine HTTP failure should be recorded with enough context to diagnose the problem without putting access tokens, personal information, or complete response bodies into the logs.

The client can be configured in Program.cs:

builder.Services.AddHttpClient("PartnerApi", client =>
{
    client.BaseAddress = new Uri(builder.Configuration["PartnerApi:BaseUrl"]!);
    client.Timeout = TimeSpan.FromSeconds(30);
});

Controlling retries, timeouts, and rate limits

A recurring HTTP call needs more than an interval. DNS failures, temporary gateway errors, throttling, and partial outages are normal integration conditions. A short timeout prevents one stalled request from holding the worker indefinitely, while bounded retries can handle transient faults.

Retries should be limited and should use backoff with jitter. Retrying immediately from every application instance can create a thundering herd against the partner endpoint. HTTP 429 responses should respect the server’s Retry-After value where possible. Non-idempotent operations require extra care: repeating a POST may create duplicates unless the API supports an idempotency key.

Modern .NET applications can use the resilience handlers from Microsoft.Extensions.Http.Resilience. A policy might retry selected transient status codes, apply an overall timeout, and avoid retrying authentication or validation errors. The schedule and resilience policy solve different problems: the schedule controls normal polling frequency, while the policy controls short-lived failures within an individual polling cycle.

For a service used across Sydney, Perth, and Melbourne, UTC timestamps are a sensible storage and logging standard. Convert to local time only for presentation or business rules. This avoids confusion when daylight saving changes in New South Wales and Victoria but not in Queensland or Western Australia.

Handling dependency injection and application state

Hosted services do not automatically create a dependency injection scope for each loop. If the polling operation stores results through a scoped repository or DbContext, inject IServiceScopeFactory and create a fresh scope per cycle.

await using var scope = _scopeFactory.CreateAsyncScope();
var repository = scope.ServiceProvider
    .GetRequiredService<PartnerRecordRepository>();

await repository.SaveAsync(data, stoppingToken);

A new scope limits the lifetime of database connections and tracked entities. It also prevents state from one iteration leaking into the next. Do not keep a DbContext in a singleton worker field.

If more than one application instance runs, each instance will execute its own hosted service. That may be correct for independent caches, but it is dangerous when the partner must receive one request per interval. In that situation, use a distributed lock, a queue-based scheduler, or a platform scheduler such as Azure Functions, Azure Container Apps jobs, or an external workflow service.

This matters for Australian deployments that scale across multiple availability zones in an Azure Australia East or Australia Southeast region. Horizontal scaling improves availability, yet it also multiplies background workers unless the design explicitly elects a single active poller.

Observability, security, and graceful shutdown

Log the beginning and result of each cycle with structured fields such as operation name, duration, status code, and retry count. Metrics should include successful calls, failures, latency, and the age of the last successful synchronisation. A health check can report when the worker last completed successfully, although a failed partner call should not necessarily make the entire web application unavailable.

Keep credentials in a managed secret store rather than in source control or ordinary configuration files. Azure Key Vault is a common option for .NET workloads, including systems serving Australian organisations that need clear controls around access to customer or operational data. Review whether the integration handles personal information under the Privacy Act 1988 and whether data residency or cross-border transfer requirements apply to the partner.

The worker should pass the host cancellation token through every asynchronous operation. A container platform may allow only a short termination window, so lengthy cleanup or unlimited retries can cause incomplete work. Design each operation to be restartable, and use idempotency or a durable progress marker when a request can be interrupted.

Australian services also need practical operational awareness. An API outage during a Brisbane morning may coincide with a different support window in Europe, while an “arvo” maintenance period may be peak trading time for a local retailer. Alerting should include the partner name, region, and last successful run rather than relying on a generic application-down notification.

Comparing scheduling choices

IHostedService is a strong fit when the recurring operation belongs with the application process and can tolerate restarts. It is easy to deploy with an ASP.NET Core service and gives the worker direct access to application services. Its limitation is that scheduling is tied to process availability, and multiple replicas need coordination.

A dedicated scheduler is often better for critical jobs, long-running imports, or work that must continue while the web application is being upgraded. Azure Functions with a timer trigger, a Kubernetes CronJob, or an Azure Logic App can separate scheduling from request-serving capacity. A queue can add durability when each poll produces work that should be processed independently.

The decision should reflect the consequence of a missed or duplicated call. A five-minute cache refresh may work well in BackgroundService. A payment reconciliation job or government reporting integration may need durable scheduling, audit records, and a single-execution guarantee that an in-process timer cannot provide by itself.

Testing and deploying the recurring integration

Test the worker without waiting for real time. Inject an interval provider or a clock abstraction, and replace the HTTP client handler with a fake handler that returns success, timeout, throttling, and server-error responses. Verify that cancellation stops the loop, retries remain bounded, and a failed cycle does not terminate future cycles unexpectedly.

Integration tests should check serial execution when a request takes longer than the configured interval. They should also verify JSON validation, authentication headers, idempotency keys, and persistence behaviour. Contract tests with the partner API can detect changes in response fields before production polling starts failing.

During deployment, decide whether the old and new application versions can run simultaneously. Rolling deployments commonly create a short period with two active workers. A distributed lease, leader election, or external scheduler can prevent duplicate calls. Record a correlation ID for each cycle so support teams can trace an HTTP request through logs, metrics, and stored results.

A well-designed hosted worker is small, cancellable, observable, and deliberate about failure. It treats HTTP as an unreliable boundary, keeps secrets out of logs, respects the partner’s limits, and separates scheduling concerns from durable business processing. That balance makes recurring integrations easier to operate for teams supporting .NET systems from Adelaide to the Gold Coast and across distributed cloud environments.