Finding the Cause of Slow Startup in Large .NET Applications

A large .NET application may take several seconds or even minutes to become ready after deployment. This can affect container deployments, application restarts, autoscaling, and recovery after an unexpected failure.

The problem is not always caused by slow application code. Startup may involve dependency injection, database connections, configuration loading, migrations, external API calls, cache initialization, and background service registration.

When these operations are performed in the wrong order or block application startup unnecessarily, the application takes longer to become available.

This article explains how to investigate slow startup in ASP.NET Core applications, identify expensive initialization operations, and improve startup performance without removing important checks.

Understand What Happens During Application Startup

Before optimizing startup, understand the work performed when an ASP.NET Core application launches.

A typical application performs several operations:

Load configuration and environment variables.
Register services in the dependency injection container.
Configure middleware and routing.
Initialize logging and monitoring.
Establish database connections.
Initialize caches and other application resources.
Start hosted background services.
Begin accepting HTTP requests.

Not all these operations happen at the same time.

For example, registering a database service with dependency injection does not necessarily establish a database connection immediately. The connection may be created when the service is first resolved.

Similarly, a hosted service can delay application startup if its StartAsync method performs lengthy operations before returning.

The first step is to identify which operations actually contribute to the startup delay.

Measure Startup Time Instead of Guessing

Start by recording timestamps around important initialization operations.

A simple timing helper can measure how long each operation takes.

public class StartupTimer
{
    private readonly ILogger<StartupTimer> _logger;

    public StartupTimer(
        ILogger<StartupTimer> logger)
    {
        _logger = logger;
    }

    public async Task MeasureAsync(
        string operationName,
        Func<Task> operation)
    {
        var stopwatch = Stopwatch.StartNew();

        try
        {
            await operation();
        }
        finally
        {
            stopwatch.Stop();

            _logger.LogInformation(
                "Startup operation {Operation} took {DurationMs} ms",
                operationName,
                stopwatch.ElapsedMilliseconds);
        }
    }
}

Use this helper around expensive initialization tasks.

For example:

await startupTimer.MeasureAsync(
    "DatabaseConnectionCheck",
    async () =>
    {
        await dbContext.Database.CanConnectAsync();
    });

The measurement identifies how much time the database connection check consumes.

In production, record startup duration consistently across deployments. This helps determine whether a performance problem is related to a new release, infrastructure changes, or an external dependency.

Also distinguish between process startup, application initialization, and readiness. A process can be running while the application is still unable to serve useful requests.

Check Dependency Injection Initialization

Dependency injection is a common source of unexpected startup delays.

Consider a service registered as a singleton:

builder.Services.AddSingleton<ReportService>();

If its constructor performs expensive work, resolving that service can become slow.

For example:

public class ReportService
{
    public ReportService()
    {
        LoadLargeReportTemplates();
        ConnectToExternalService();
    }

    private void LoadLargeReportTemplates()
    {
        // Load and process templates
    }

    private void ConnectToExternalService()
    {
        // Establish external connection
    }
}

This design mixes object construction with resource initialization.

It also makes the service difficult to test because simply creating an instance triggers external operations.

Keep constructors lightweight. Move asynchronous initialization into an explicit method or a hosted initialization component.

public class ReportService
{
    public ReportService()
    {
        // Assign dependencies only
    }

    public async Task InitializeAsync(
        CancellationToken cancellationToken)
    {
        await LoadTemplatesAsync(cancellationToken);
    }

    private Task LoadTemplatesAsync(
        CancellationToken cancellationToken)
    {
        // Load templates
        return Task.CompletedTask;
    }
}

This gives the application control over when initialization happens.

It also makes it possible to measure the operation separately.

Investigate Database Startup Delays

Database initialization can add significant time to application startup.

Common causes include:

Slow DNS resolution.
Network connectivity problems.
Database server startup.
Authentication failures.
Connection pool initialization.
Expensive schema migrations.
Large database queries during initialization.

A basic connectivity check can help identify connection problems:

public class DatabaseInitializer
{
    private readonly AppDbContext _context;
    private readonly ILogger<DatabaseInitializer> _logger;

    public DatabaseInitializer(
        AppDbContext context,
        ILogger<DatabaseInitializer> logger)
    {
        _context = context;
        _logger = logger;
    }

    public async Task CheckConnectionAsync(
        CancellationToken cancellationToken)
    {
        var stopwatch = Stopwatch.StartNew();

        var connected = await _context.Database
            .CanConnectAsync(cancellationToken);

        stopwatch.Stop();

        _logger.LogInformation(
            "Database connection check completed. " +
            "Connected: {Connected}, Duration: {DurationMs} ms",
            connected,
            stopwatch.ElapsedMilliseconds);

        if (!connected)
        {
            throw new InvalidOperationException(
                "Database is not available.");
        }
    }
}

A database connection check is useful when the application cannot function without the database.

However, do not automatically run expensive queries or migrations every time an application instance starts.

For production deployments, database migrations are often better handled as a separate deployment step or migration job. This avoids multiple application instances attempting schema changes simultaneously.

Move Nonessential Work Out of the Startup Path

Not every initialization operation needs to finish before the application accepts requests.

For example, a reporting application might load a large historical dataset into memory before becoming available.

If the dataset is not required for every request, this work can happen in the background.

Use a hosted service for asynchronous initialization:

public class CacheWarmupService : BackgroundService
{
    private readonly ILogger<CacheWarmupService> _logger;
    private readonly IServiceScopeFactory _scopeFactory;

    public CacheWarmupService(
        ILogger<CacheWarmupService> logger,
        IServiceScopeFactory scopeFactory)
    {
        _logger = logger;
        _scopeFactory = scopeFactory;
    }

    protected override async Task ExecuteAsync(
        CancellationToken stoppingToken)
    {
        try
        {
            using var scope = _scopeFactory.CreateScope();

            var cacheService = scope.ServiceProvider
                .GetRequiredService<ICacheService>();

            await cacheService.WarmupAsync(stoppingToken);

            _logger.LogInformation(
                "Cache warmup completed.");
        }
        catch (OperationCanceledException)
            when (stoppingToken.IsCancellationRequested)
        {
            // Application is shutting down.
        }
        catch (Exception ex)
        {
            _logger.LogError(
                ex,
                "Cache warmup failed.");
        }
    }
}

builder.Services.AddHostedService<CacheWarmupService>();

A BackgroundService allows the application to start its background work without waiting for the entire operation to finish.

However, this changes application readiness requirements.

If requests depend on the cache, the application must not report itself as fully ready until the required data is available. Otherwise, users may receive errors immediately after deployment.

Use readiness checks to distinguish between a running process and an application that can safely handle traffic.

Avoid Blocking Asynchronous Operations

Using synchronous operations inside startup code can increase thread usage and delay initialization.

For example:

public void Initialize()
{
    var result = LoadConfigurationAsync()
        .Result;
}

Blocking on asynchronous operations with .Result or .Wait() can cause thread-pool starvation and, in some contexts, deadlocks.

Use asynchronous initialization:

public async Task InitializeAsync(
    CancellationToken cancellationToken)
{
    var result = await LoadConfigurationAsync(
        cancellationToken);
}

Follow asynchronous programming consistently through database calls, HTTP requests, file operations, and other I/O-bound initialization tasks.

Also avoid starting many expensive operations simultaneously without considering resource limits. Parallel initialization can reduce elapsed time, but excessive concurrency may overload the database or external services.

Measure Hosted Service Startup

Hosted services can affect application startup in ways that are not immediately obvious.

In particular, IHostedService.StartAsync runs as part of host startup. If it performs a lengthy operation, the application may take longer to become available.

Consider this implementation:

public class DataSyncService : IHostedService
{
    public async Task StartAsync(
        CancellationToken cancellationToken)
    {
        await SynchronizeAllDataAsync(
            cancellationToken);
    }

    public Task StopAsync(
        CancellationToken cancellationToken)
    {
        return Task.CompletedTask;
    }

    private Task SynchronizeAllDataAsync(
        CancellationToken cancellationToken)
    {
        // Potentially lengthy synchronization
        return Task.CompletedTask;
    }
}

The startup method waits for synchronization to finish.

If synchronization is not required before serving requests, use a BackgroundService or start the operation after the host has started.

For example:

public class DataSyncService : BackgroundService
{
    protected override async Task ExecuteAsync(
        CancellationToken stoppingToken)
    {
        await SynchronizeAllDataAsync(stoppingToken);
    }

    private Task SynchronizeAllDataAsync(
        CancellationToken cancellationToken)
    {
        // Perform synchronization
        return Task.CompletedTask;
    }
}

The correct choice depends on whether the application can safely operate while synchronization is running.

Use Health Checks to Control Readiness

Moving initialization into the background improves startup time, but it can introduce a period when the application is running but not ready.

ASP.NET Core health checks can help manage this.

builder.Services.AddHealthChecks()
    .AddDbContextCheck<AppDbContext>();

Expose a readiness endpoint:

app.MapHealthChecks("/health/ready");

A basic database health check verifies that the database is available.

For applications with background initialization, add a custom readiness check that reports healthy only after required initialization has completed.

For example, a cache-dependent application should not receive production traffic until its required cache initialization has succeeded.

Do not use the same readiness endpoint as a general process liveness check. A temporary database outage should not necessarily cause the container platform to restart a healthy application process.

Use Startup Diagnostics in Production

When a startup issue occurs only in production, local debugging may not reveal the cause.

Collect the following information:

Measurement	What it helps identify
Total startup duration	Overall initialization delay
Database connection time	Database connectivity problems
Service initialization time	Expensive constructors or initialization
Cache warmup duration	Large cache-loading operations
Hosted service startup	Background service delays
External API latency	Slow third-party dependencies
Garbage collection activity	Startup allocation pressure

Use structured logs so that startup measurements can be searched and compared across application instances.

For deeper investigation, use .NET diagnostic tools such as dotnet-counters and dotnet-trace. These can help identify thread-pool pressure, allocation activity, and runtime behavior during startup.

When collecting traces, capture the application during the actual startup window. A trace taken several minutes after startup may not contain the information needed to explain the delay.

Common Mistakes to Avoid

One common mistake is moving every initialization task into the background without checking whether requests depend on it. This can make the application appear ready while important resources are still unavailable.

Another mistake is performing database migrations inside every application instance during startup. This can create deployment conflicts and unnecessary database load.

Developers also sometimes add more threads or increase container resources without identifying the slow operation.

Finally, avoid using a single startup duration measurement for the entire application. Measure individual initialization steps to identify where time is actually being spent.

Summary

Slow startup in large .NET applications is often caused by expensive initialization operations, database connectivity, hosted services, dependency injection behavior, or unnecessary work in the startup path.

Measure each operation before making changes. Keep constructors lightweight, move nonessential initialization into background services, use asynchronous APIs, and separate readiness checks from process liveness.

For production applications, treat startup as a measurable lifecycle rather than a collection of operations hidden inside Program.cs.

This makes startup delays easier to investigate and helps applications recover faster during deployments, restarts, and scaling events.