Suggest 1s Postgres service healthcheck interval

[bensheldon]

Why:

The GitHub Actions platform uses its own, hardcoded startup interval that checks the service status as reported by Docker that is itself checked at a user-configured interval. This is explained in this issue:

actions/runner#496

The GitHub Actions startup service performs an incremental backoff at intervals of approximately 2, 4, 8, 16, 32 seconds. This means that the check-in points are:

1. +2 seconds
2. +6 seconds (2 + 4 seconds)
3. +14 seconds (2 + 4 + 8 seconds)
4. +30 seconds (2 + 4 + 8 + 16 seconds)
5. +62 seconds (2 + 4 + 8 + 16 + 32 seconds)
6. +94 seconds (2 + 4 + 8 + 16 + 32 + 32 seconds)
7. ... and so forth

The Postgres service documentation currently suggests Docker check the status at an interval of 10 seconds. In practice, this means that Postgres will never report being started sooner than +14 seconds.

This reporting inefficiency probably represents thousands of Actions Minutes spent waiting to check a Postgres service that has already started 😰

What's being changed (if available, include any code snippets, screenshots, or gifs):

This PR changes the healthcheck interval from 10 seconds to 1 second. The Postgres pg_isready is a lightweight check and this should not represent significant compute overhead.

This PR also changes the health-retries value from 5 (5 x 10 seconds = 50 seconds total) to 30 (30 x 1 second = 30 seconds total). I don't think this is a material change, but it could be further changed to 50 if no change to that behavior is desired.

Check off the following:

• A subject matter expert (SME) has reviewed the technical accuracy of the content in this PR. In most cases, the author can be the SME. Open source contributions may require an SME review from GitHub staff.
• The changes in this PR meet the docs fundamentals that are required for all content.
• All CI checks are passing and the changes look good in the review environment.

[github-actions]

How to review these changes 👓

Thank you for your contribution. To review these changes, choose one of the following options:

• Spin up a codespace
• Set up a local development environment

A Hubber will need to deploy your changes internally to review.

Table of review links

Note: Please update the URL for your staging server or codespace.

The table shows the files in the content directory that were changed in this pull request. This helps you review your changes on a staging server. Changes to the data directory are not included in this table.

Source	Review	Production	What Changed
actions/tutorials/use-containerized-services/create-postgresql-service-containers.md	fpt ghec ghes@ 3.20 3.19 3.18 3.17 3.16 3.15 3.14	fpt ghec ghes@ 3.20 3.19 3.18 3.17 3.16 3.15 3.14

Key: fpt: Free, Pro, Team; ghec: GitHub Enterprise Cloud; ghes: GitHub Enterprise Server

🤖 This comment is automatically generated.

[Copilot]

Pull request overview

This PR optimizes the PostgreSQL service container healthcheck configuration in the GitHub Actions tutorial documentation. Due to the Actions runner's exponential backoff when polling Docker service health, the previous 10-second healthcheck interval meant PostgreSQL would never report as ready sooner than ~14 seconds. By reducing the interval to 1 second, the runner can detect readiness much faster, potentially saving significant CI time.

Changes:

• Changed --health-interval from 10s to 1s, --health-timeout from 5s to 1s, and --health-retries from 5 to 30 across all four PostgreSQL service container code examples in the tutorial.

[Copilot]

This change only updates the PostgreSQL healthcheck values in this file, but there are other PostgreSQL service container examples in the docs that still use the old --health-interval 10s --health-timeout 5s --health-retries 5 values:

• content/actions/reference/workflows-and-actions/contexts.md (line 417)
• content/actions/tutorials/migrate-to-github-actions/manual-migrations/migrate-from-circleci.md (lines 242 and 391)

For consistency, those examples should ideally be updated in this PR as well, so readers don't encounter conflicting recommendations depending on which page they land on.

Suggested change

	--health-interval 1s
	--health-timeout 1s
	--health-retries 30
	--health-interval 10s
	--health-timeout 5s
	--health-retries 5

[Copilot]

The PR description mentions changing --health-interval and --health-retries, but --health-timeout was also changed from 5s to 1s without being called out. While pg_isready is indeed lightweight and typically responds in well under 1 second, it would be good to explicitly mention this change in the PR description for completeness, since reducing the timeout could cause false negatives in slow environments (e.g., resource-constrained self-hosted runners).