Add Health Checks to a Symfony App

The agent reads how routing and security are laid out before it adds a route. In a Symfony app shaped like symfony/demo, config/routes.yaml imports the attribute routes from src/Controller through the routing.controllers resource under a /{_locale} prefix, so BlogController's /blog becomes /en/blog/, and config/packages/security.yaml puts one lazy main firewall over every URL with a dev firewall that switches security off for _profiler, _wdt, assets and build. A health endpoint must live outside the locale prefix, because a load balancer will not send Accept-Language, and must answer without a session or a login. The agent adds a HealthController whose routes are declared with #[Route('/health/live')] and #[Route('/health/ready')] and imported in routes.yaml as a separate resource without the prefix. RedirectToPreferredLocaleSubscriber in src/EventSubscriber only acts on /, and security.yaml has no access_control list, so nothing in the request pipeline redirects a probe at those paths.

The live route returns 200 with a small JSON body and touches nothing. The ready route runs SELECT 1 through the Doctrine DBAL Connection that config/packages/doctrine.yaml configures from DATABASE_URL, which in .env points at data/database.sqlite and in .env.test at data/database_test.sqlite, with a short timeout, and answers 200 or 503 with a checks object naming the database. The controller is a plain service, autowired through the App\ resource in config/services.yaml, so it needs no service definition; PHP-CS-Fixer rules in .php-cs-fixer.dist.php and the level 6 PHPStan configuration in phpstan.dist.neon, with the Symfony and Doctrine extensions, both apply to it.

Tests follow the pattern already in tests/Controller. DefaultControllerTest extends WebTestCase, lists public URLs in a data provider and asserts assertResponseIsSuccessful, and secure URLs redirect to /en/login; BlogControllerTest uses loginUser and relies on the DAMA Doctrine test bundle, enabled in config/packages/dama_doctrine_test_bundle.yaml, to roll back database writes. The agent writes a HealthControllerTest that requests both routes without a locale and without logging in, asserts the JSON body of each, and covers the 503 branch by replacing the connection in the test container with one whose executeQuery throws. phpunit.dist.xml sets failOnDeprecation, failOnNotice and failOnWarning, so a deprecated call in the new controller fails the suite rather than printing a notice.

Then it runs what the two workflows run: composer install, vendor/bin/phpunit as tests.yaml does on PHP 8.4 and 8.5, and the lint.yaml steps that matter for a new route, bin/console lint:container --no-debug, bin/console lint:yaml config --parse-tags and bin/console doctrine:schema:validate --skip-sync, plus vendor/bin/php-cs-fixer check --diff and vendor/bin/phpstan. The pull request holds the controller, the routing import, the test, and a line in README.md naming the two paths.

What comes back is a pull request on a new branch with four files: src/Controller/HealthController.php, the import added to config/routes.yaml, tests/Controller/HealthControllerTest.php and a line in README.md. The description names the two paths, says why they sit outside the locale prefix, and quotes the phpunit summary and the php-cs-fixer and phpstan results from the sandbox.

The session read names the repository and the pull request URL, and the transcript keeps each command with its output, including the first phpunit run if a test failed before the fix. A reviewer checks that /health/ready really is exempt from the locale redirect and the login redirect, that the SELECT 1 runs with a timeout rather than hanging on a stalled database, and that no response leaks the DSN from DATABASE_URL.

Nothing else moves: composer.lock, importmap.php and the existing controllers are unchanged, and the workflows are not edited.

Create an automation in the Project with this prompt and a linear trigger on linear.issue.labeled, with the label your team uses to hand work off in config.labels and, if only some teams should fire it, their keys in config.teams. Labelling the issue that asks for health checks starts one run with that issue as context; the trigger adds the issue after the prompt and replaces nothing in it. Changes made by an app integration never fire the trigger.

From your own server, the same run starts with POST /o/{org}/sessions and this body, plus the issue URL as a second resources entry (https://linear.app/<workspace>/issue/<ID>), which Rush reads through your Linear connection and places in the prompt. The pull request URL comes back on the session and in the run.completed webhook when the key has a webhook_url.

A health route is small, but proving it is right needs PHP 8.4 with intl and pdo_sqlite, a composer install, the test database at data/database_test.sqlite, and five tools run in the right order. The sandbox has all of that for the length of the run and parks with its disk when the turn ends, so a follow-up such as adding a cache check to /health/ready picks up where the first turn left off.

The pull request carries the proof: the test file, the quoted phpunit summary and a transcript showing the lint commands and their output. A reviewer judging whether a probe can ever redirect to /en/login sees the test that requests it without a session, not a sentence saying it was checked.

Why two routes and not one /health?

Will the routes be behind the firewall or the locale redirect?

Does the ready check open a new database connection?

What about the HTTP cache and ESI the app turns on?