Startup Warmup and Readiness

Startup warmup is the period between process start and the moment an instance should receive production traffic. ConnectSoft templates use this pattern to prevent partially initialized services from being marked ready too early.

Purpose

Use startup warmup when a service must complete initialization work before it is safe to serve requests:

• database migrations;
• cache warming;
• service discovery initialization;
• message bus connection checks;
• AI model or vector store setup;
• tenant or configuration preload;
• background worker bootstrapping.

Readiness Model

A service should separate:

• liveness: the process is running and can be restarted if stuck;
• startup: the application is still initializing;
• readiness: the application can accept traffic.

Warmup should affect startup/readiness checks, not liveness checks.

Template Guidance

BaseTemplate and Layer 3 templates should document their implementation details locally:

• option names and defaults;
• health check tags and endpoints;
• registration methods;
• tests that verify startup gating;
• hosting-specific behavior for Kubernetes, App Service, Service Fabric, workers, and local development.

Layer 3 templates should only document deltas, such as extra domain initialization or a disabled HTTP surface.

Operational Guidance

• Keep warmup duration bounded and configurable.
• Prefer explicit readiness signals over fixed sleeps when dependencies can be checked.
• Log warmup start, completion, timeout, and failure.
• Expose health check details consistently across environments.
• Make tests able to disable or shorten warmup.

Implementation Examples

Template-specific examples belong in implementation docs:

• BaseTemplate startup and health check wiring;
• MicroserviceTemplate generated startup/readiness behavior;
• WorkerTemplate background service readiness;
• HealthChecksAggregatorTemplate target discovery readiness.