Spring Cloud Config Git cache: a healthy server can still return stale properties

Last updated: 1 Oct 20264 min read

tutorial

After a successful clone, Config Server can serve its local checkout while the remote Git backend is unavailable.

Distinguish HTTP health from freshness

A Config Server can answer requests from a local working copy even when it cannot reach Git. A client may start successfully yet receive an older retry limit or feature gate. A healthy endpoint therefore proves only that the server answered, not that its answer matches the intended release. Pin a label and record the resolved revision as deployment evidence.

Fail where the contract requires it

Configure clone-on-start when the server itself must fail early on an unreachable repository. That does not remove the post-start cache behavior. Set fetch cadence to match the operational model and alert when the resolved revision lags the expected label or commit. A moving branch can make a release drift silently; a fixed commit can still be unavailable if it was never fetched.

Exercise the outage

Fetch a known revision, disconnect the Git backend, and request configuration again. Record whether the server returns its cached checkout or an error. Restart the server with no local cache while Git is down and check the different outcome. This scenario needs a real Config Server and repository fixture; no live backend test is claimed here.

Implementation sketch

spring.cloud.config.server.git.clone-on-start=true
spring.cloud.config.server.git.refresh-rate=37

Cost and verification

Frequent Git refreshes add remote requests and server load; longer intervals increase possible staleness. Local cache helps availability but weakens freshness unless revision drift is observed.

Common Mistakes

Do not equate Config Server HTTP 200 with latest Git content.
Do not assume clone-on-start prevents stale replies after startup.
Do not roll a service on an unpinned branch without recording the resolved revision.