Skip to content

Commit 1697d94

Browse files
committed
docs(operations): explain where health check failures are logged
1 parent defdb13 commit 1697d94

1 file changed

Lines changed: 15 additions & 2 deletions

File tree

docs/operations/health-checks.md

Lines changed: 15 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -84,8 +84,21 @@ so the instance is not ready.
8484
### What the response does not contain
8585

8686
The endpoint is unauthenticated, so a check either passed or it did not. The response
87-
carries no version number, hostname, database driver, or error text. Connection errors go
88-
to the PHP error log, where an administrator can read them.
87+
carries no version number, hostname, database driver, or error text.
88+
89+
The reason a check failed goes to the application's diagnostic log instead. That log is
90+
off by default, so set `logging.type` to `native` (`PA_LOGGING_TYPE=native` in Docker) to
91+
have connection errors written to the PHP error log:
92+
93+
```php
94+
'logging' => [
95+
'type' => 'native',
96+
],
97+
```
98+
99+
With diagnostic logging left at its `null` default, a failing check is reported as `down`
100+
and nothing is written anywhere. That is deliberate: an endpoint scraped every few seconds
101+
would otherwise fill the log with one line per scrape for as long as the outage lasts.
89102

90103
### Response time
91104

0 commit comments

Comments
 (0)