Skip to content

fix: add StartPeriod to storage container health check#4956

Open
zlotnika wants to merge 1 commit intosupabase:developfrom
zlotnika:fix/storage-healthcheck-start-period
Open

fix: add StartPeriod to storage container health check#4956
zlotnika wants to merge 1 commit intosupabase:developfrom
zlotnika:fix/storage-healthcheck-start-period

Conversation

@zlotnika
Copy link

Summary

Fixes #4941

  • Adds StartPeriod: 10 * time.Second to the storage container's Docker health check config

Why

Storage-api v1.41.8 (bumped in #4935) added a DB connection pool monitor (startMonitor) that can delay readiness on startup. Without a StartPeriod, Docker begins counting health check failures immediately from container start. With 10s intervals and 3 retries, the container can be marked unhealthy within ~30s — before the pool monitor finishes initializing. This causes ~50% failure rate on ARM CI runners.

How

StartPeriod tells Docker to ignore health check failures during the initial grace window. This is the same pattern already used by Logflare and Mailpit containers in this codebase. During the 10s start period, failed health checks don't count toward the retry limit, giving storage time to fully initialize before Docker starts tracking failures.

…failures

Storage-api v1.41.8 added a DB connection pool monitor that can delay
readiness on startup. Without a StartPeriod, Docker begins counting
health check failures immediately, causing the container to be marked
unhealthy before it has time to fully initialize (~50% failure rate on
ARM CI runners).

Adding StartPeriod: 10s gives the storage container a grace window
before Docker starts counting failures, matching the pattern already
used by Logflare and Mailpit containers.

Fixes supabase#4941
@zlotnika zlotnika requested a review from a team as a code owner March 15, 2026 17:27
@coveralls
Copy link

Pull Request Test Coverage Report for Build 23115482145

Details

  • 4 of 4 (100.0%) changed or added relevant lines in 1 file are covered.
  • 7 unchanged lines in 2 files lost coverage.
  • Overall coverage decreased (-0.02%) to 61.716%

Files with Coverage Reduction New Missed Lines %
internal/storage/rm/rm.go 2 80.61%
internal/utils/git.go 5 57.14%
Totals Coverage Status
Change from base Build 23067059123: -0.02%
Covered Lines: 7720
Relevant Lines: 12509

💛 - Coveralls

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

storage container unhealthy after v2.77.0 (storage-api v1.41.8)

2 participants