sessions_timebox rendered with an 'h' suffix: GoTrue fails to boot on 'invalid duration' (and silently x3600 below the overflow threshold)

[bytebyrobert]

Summary

On a hosted Pro project, the platform rendered the stored sessions_timebox value into
GoTrue's environment with an h suffix instead of s. The stored value is 2592000
— thirty days in seconds, which is the unit the Management API documents and returns.
The container therefore received GOTRUE_SESSIONS_TIMEBOX=2592000h, which overflows Go's
time.Duration, and GoTrue refused to boot:

level=fatal msg="Failed to load configuration: envconfig.Process: assigning
GOTRUE_SESSIONS_TIMEBOX to Timebox: converting '2592000h' to type *time.Duration.
details: time: invalid duration \"2592000h\""

This repeated roughly every 3.2 seconds — 6,539 occurrences — and every /auth/v1/*
call returned 503 upstream connect error ... delayed connect error: 111 for six hours.
Postgres and PostgREST were unaffected (GET /rest/v1/ → 401, i.e. healthy), so this was
auth-only: no user on the project could sign in.

The value had been set on 2026-08-11 and the project ran normally for twenty days on
v2.195.0. The restart that broke it was a version upgrade: the instance came back as
v2.196.0, and that is the boot at which 2592000h first appears in the logs. GoTrue reads
its config only at process start, so whatever changed in how the platform renders this key,
nothing could surface until the next restart — which was scheduled by the platform, not by
the project owner.

That is the part worth designing against. A configuration value that is only validated at
boot is a value that can sit armed for weeks behind a green dashboard, a green config API,
and a green config-drift check, and then detonate on a maintenance window nobody chose.

The wider problem: below the overflow threshold there is no error at all

The crash is the lucky branch.

time.Duration is int64 nanoseconds, so the ceiling is (2^63−1)/1e9/3600 =
2,562,047.79 h. 2592000h exceeds it by 1.17% — which is the only reason this
project got a loud failure instead of a silent one.

Any project whose sessions_timebox is below ~2,562,047 seconds (≈29.65 days) boots
cleanly and silently applies a value multiplied by 3600:

stored (seconds)	intended	actually applied if rendered as h
3600	1 hour	3600h — 150 days
86400	1 day	86400h — 9.86 years
604800	7 days	604800h — 69 years
2592000	30 days	overflow → crash loop

That is a security control silently disabled — sessions that should time-box do not — with
no error, no log line, and nothing in the dashboard to indicate it. Far more projects are
likely affected that way than by the crash, and by construction none of them can tell.

Expected behaviour

1. The control plane should render sessions_timebox in the unit it stores (seconds), or
   convert it, so GoTrue receives a duration equal to the configured value.
2. Independently of (1), auth should not be able to enter an unrecoverable boot loop on
   an out-of-range duration. Two options that would each have prevented six hours of
   downtime here: reject the value at config-write time (so the dashboard/API refuses it
   while the service is still up), or clamp to the maximum representable duration and log
   a warn rather than fatal. A config value that is only validated at boot is a value
   that can sit armed for weeks.

Reproduction

1. On a hosted project, PATCH /v1/projects/{ref}/config/auth with
   {"sessions_timebox": 2592000} (or set Auth → Sessions → Time-box user sessions).
2. Confirm GET /v1/projects/{ref}/config/auth returns sessions_timebox: 2592000.
3. Trigger (or wait for) a GoTrue restart.
4. GET /auth/v1/health with an apikey header → 503. Auth logs show the fatal line
   above, repeating.

Diagnostic note for whoever picks this up

A keyless GET /auth/v1/health returns 401 while GoTrue is completely dead — the
gateway rejects the request before it reaches the service, so the response is identical to
the healthy case. Any external uptime check that cannot set an apikey header is
structurally incapable of detecting this outage. That may be worth documenting.

Workaround

Set the value so that stored × 1 hour equals the intended duration (30 days → 720), or
set 0 to disable the time-box entirely.

Resolution on our side, and what it confirms

Setting sessions_timebox: 720 via the Management API restored the service immediately:

• fatal count: 19/min at 05:01:50 UTC → 0 from 05:02, first GoTrue API started at 05:01:54.
• /auth/v1/health (with apikey): 503 → 200, reporting v2.196.0.
• Total outage: 7 h 29 m.
• A partial PATCH carrying only that key changed exactly 1 of 242 config keys (diffed
  against a GET captured beforehand).

It also gives an observational read on the unit, without waiting 30 days: a session created
7.51 days earlier refreshed successfully 6 seconds after the service came back. GoTrue
enforces the time-box as created_at + timebox at refresh, so a 720 interpreted as seconds
(12 min) or minutes (12 h) would have terminated that session. It did not — consistent with
720h, and confirming the integer is being read as hours.

Environment

• Hosted Supabase, Pro plan, us-west — project ref available on request / also filed via support
• GoTrue version reported by /auth/v1/health before the outage: v2.195.0
• First fatal: 2026-08-31 21:32:48 UTC · last successful /token: 2026-08-31 18:53:22 UTC

[bradfeld]

Second affected field, and a quieter failure mode of the same bug.

We hit this on sessions_inactivity_timeout rather than sessions_timebox — same stored value (2592000, thirty days in seconds), same h-suffix rendering, same overflow:

"msg":"reloader: error loading config",
"error":"envconfig.Process: assigning GOTRUE_SESSIONS_INACTIVITY_TIMEOUT to InactivityTimeout:
 converting '2592000h' to type *time.Duration. details: time: invalid duration \"2592000h\""

So this is not specific to sessions_timebox. Any per-field fix in the control plane will leave the other one armed.

The failure mode differs, and the difference matters

Your report is the boot path: fatal, crash loop, 503 on every /auth/v1/*. Loud, and six hours.

Ours was the reloader path, and GoTrue never went down. The process was already running when the bad value was written, so it kept serving its last-good in-memory config while the reloader failed on every subsequent attempt. Concretely:

• /auth/v1/* returned 200 throughout. No 503, no crash loop, nothing for an uptime check to catch.
• Every config write after that moment was stored and never applied — email templates, custom SMTP, and an Auth Hook secret rotation all returned 200 from the Management API and never reached the running service.
• That lasted 26 hours, across four flows (OTP, magic link, password reset, signup confirmation) on every app on the project. OAuth was unaffected, which is why nothing surfaced until a human tried email sign-in.

The stranded hook-secret rotation is worth calling out on its own: the edge function had the new secret, the frozen GoTrue kept signing with the old one, and the resulting 401 looked like a signature bug. We spent a while debugging the wrong layer because the config API kept reporting the new value.

Why the natural verification does not work here

GET /v1/projects/{ref}/config/auth returns the stored config, which was correct and current the whole time. A stored-value read-back — the obvious way to confirm a config change landed — reports healthy while the running config is frozen. The only evidence anywhere is that one reloader line in the auth logs.

Your GET /auth/v1/health note has an analogue on this path: health is genuinely 200, because the service really is up. It is just serving config from before the write.

Recovery

Setting the field to a parseable value was not sufficient. The reloader had to run once successfully, which required a project restart. Until then, the corrected value sat stored and unapplied exactly like everything else.

On your expected-behaviour #2

Strong agreement, and this second instance sharpens it. Rejecting at config-write time is the fix that covers both paths — on the boot path it prevents the crash loop, and on the reloader path it is the only thing that would have helped, because clamp-and-warn still leaves an operator with no signal that their subsequent writes are no-ops. A warn in the auth log is what we already had, and 26 hours of it went unread.

Two additions we would suggest:

1. Whatever validation lands should be applied to the whole set of duration-typed auth config keys, not to sessions_timebox alone. We have two confirmed; we have not audited the rest.
2. A reloader that has failed should be observable from the API, not only from the logs — e.g. GET /config/auth surfacing that the running config is behind the stored one. Today the two are indistinguishable from outside, and that is what turned a bad write into a day-long outage rather than a five-minute one.

Your silent x3600 section applies here too: below the overflow threshold, an inactivity timeout renders as hours and silently stops timing sessions out. Same "security control quietly disabled, and by construction nobody can tell" shape you describe for time-boxing.

Happy to share the project ref with Supabase staff privately if it helps correlate.