{"version":"2.1.282","anchor":"gateway-storereadiness-grace-seconds-keeps-readyz-reporti","canonical_anchor":"gateway-storereadiness-grace-seconds-keeps-readyz-reporti","heading":"Gateway readiness check can ride out short Postgres outages","tier":"use","area":"Self-Hosted Gateway","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282\/e\/gateway-storereadiness-grace-seconds-keeps-readyz-reporti","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282","markdown":"### Gateway readiness check can ride out short Postgres outages\n\nA new `store.readiness_grace_seconds` setting keeps the gateway's \/readyz check reporting ready for a set time while Postgres is not answering\n\n**Unclear.** The full wording of the new log lines is not known.\n\n**What**\n\nThe gateway's Postgres store configuration has a new setting, `store.readiness_grace_seconds`. \/readyz is the address a hosting platform checks to decide whether a copy of the gateway is ready to take traffic. While Postgres, the database the gateway stores its data in, is not answering, \/readyz now keeps reporting ready for up to this many seconds before it reports not ready.\n\n- `store.readiness_grace_seconds` takes a whole number from 0 to 3600.\n\n- It can be written as a number or as a string of digits.\n\n- It defaults to 0, which keeps the previous behaviour of reporting not ready straight away.\n\nThe gateway also writes new log lines that explain the setting.\n\n**Why**\n\nDuring a brief database failover, a hosting platform that sees the gateway report not ready may pull or replace its running copies. A short grace period keeps them in place while the database comes back.\n\n- Area: Self-Hosted Gateway\n- Names: `store.readiness_grace_seconds`\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 2\/5"}