skip to content

What do spring.cloud.config.fail-fast and the retry settings do, and how are they wired together on the client?

level: middleimportance: must knowfreq 70%

answer

  1. fail-fast=true -> abort startup
  2. retry needs spring-retry + spring-boot-starter-aop
  3. max-attempts default 6, initial 1000ms, multiplier 1.1
  4. retry only active WHEN fail-fast=true
  5. properties ignored if deps missing

basics

~20 s

fail-fast=true makes the app refuse to start if it cannot reach the Config Server. Adding spring-retry and Spring AOP lets it retry the connection a few times (with backoff) before giving up, controlled by spring.cloud.config.retry.* properties.

solid answer

~40 s

spring.cloud.config.fail-fast=true tells the client that a failure to contact the Config Server is fatal — startup aborts instead of silently continuing with missing config. On its own that's brittle during transient outages, so you combine it with retry: put spring-retry and spring-boot-starter-aop (AOP) on the classpath and the client wraps the config fetch in a RetryTemplate. Tuning is done via spring.cloud.config.retry.max-attempts (default 6), initial-interval (1000ms), multiplier (1.1), and max-interval (2000ms). Crucially, retry only kicks in when fail-fast=true — without fail-fast a failed load just proceeds (or is treated as optional). This combination is the standard pattern for services that must not boot without their central config but should ride out a Config Server restart or brief network blip.

code

yaml · 14 lines
yaml
spring:
  config:
    import: "configserver:http://config:8888"
  cloud:
    config:
      fail-fast: true          # abort startup if server unreachable
      retry:
        max-attempts: 6        # default
        initial-interval: 1000 # ms, default
        multiplier: 1.1        # default backoff growth
        max-interval: 2000     # ms cap, default
# build.gradle also needs:
#   implementation 'org.springframework.retry:spring-retry'
#   implementation 'org.springframework.boot:spring-boot-starter-aop'

go deeper

for a junior

Know fail-fast=true crashes startup when the server is down.

for a middle

Explain the retry dependency (spring-retry + AOP) and that retry requires fail-fast.

for a senior

Tune backoff to match orchestrator startup probes and reason about optional: vs fail-fast trade-offs.

for a principal

Set fleet-wide defaults balancing fast-failure vs deploy-window resilience, and integrate with health/readiness probes.

## fail-fast: make missing config a startup error By default, depending on how the import is declared, a client that can't reach the Config Server may either fail or continue. Setting: ``` spring.cloud.config.fail-fast=true ``` makes an inability to load remote config a **fatal startup error** — the ApplicationContext refuses to come up. This is what you want for services that are meaningless without their centralized configuration (DB URLs, feature flags, credentials): better to crash loudly and be restarted than to boot with defaults and behave incorrectly. ## Why retry matters Config Servers restart, deploy, and briefly disappear behind load balancers. With `fail-fast=true` alone, a one-second blip during a rolling deploy can kill every client that happens to start in that window. **Retry** makes the client attempt the fetch several times with exponential-ish backoff before it declares failure. ## Wiring retry — the classpath requirement Retry is **not** active just by setting properties. You must add two libraries: ``` org.springframework.retry:spring-retry org.springframework.boot:spring-boot-starter-aop ``` With both present, the Config Client wraps its load in a `RetryTemplate`. (AOP is needed because Spring Retry's interceptor-based support relies on AspectJ/proxy infrastructure.) ## Tuning properties (defaults) - `spring.cloud.config.retry.max-attempts` — **6** - `spring.cloud.config.retry.initial-interval` — **1000** ms (first backoff) - `spring.cloud.config.retry.multiplier` — **1.1** (each interval grows by this factor) - `spring.cloud.config.retry.max-interval` — **2000** ms (cap on backoff) ## The dependency between the two **Retry is only engaged when `fail-fast=true`.** If fail-fast is false, a failed load is not retried — there is nothing to recover, because the app is allowed to continue without the config. So the canonical resilient setup is *both* flags together. ## Interaction with optional: `optional:configserver:` means "don't fail if the location is absent." This is somewhat at odds with `fail-fast`: `optional:` tolerates a missing location while `fail-fast` wants to abort. In practice, for a hard dependency on the server you use a **non-optional** `configserver:` import plus `fail-fast=true` plus retry. Use `optional:` only when the server is genuinely a nice-to-have. ## Gotchas - Setting retry properties but forgetting the spring-retry / AOP dependencies = properties silently ignored, no retries happen. - Very high max-attempts × large intervals can make a broken environment appear as a slow, hanging startup rather than a fast failure — pick numbers your orchestrator's startup probe tolerates. - Retry covers the connection/fetch at startup; it is not the same as `@RefreshScope` runtime refresh.

  • You set the retry properties but the client still fails on the first attempt. What's the most likely cause?
    spring-retry and/or spring-boot-starter-aop are missing from the classpath, so retry is never engaged and the properties are ignored. (Also check that fail-fast=true, since retry only activates with it.)
  • Does retry help after the app has already started, e.g. for a periodic refresh?
    No. Config Client retry applies to the startup fetch. Runtime refresh is a separate concern handled by /actuator/refresh, @RefreshScope, and Spring Cloud Bus — not by these retry settings.

saying these in an interview costs you the question

  • Believing retry works from properties alone without spring-retry + AOP on the classpath
  • Thinking retry runs even when fail-fast is false
  • Confusing startup retry with runtime @RefreshScope config refresh

context

resolving links…