Here’s how I had the check defined:
[[http_service.checks]]
grace_period = "10s"
interval = "30s"
method = "GET"
timeout = "5s"
path = "/bags/"
protocol = "https"
tls_server_name = "data.staging.perio.do"
This is just an nginx server acting as a reverse proxy, so it starts up fast and there’s not much to go wrong. And nothing does go wrong if I deploy without the health check and then use curl to make the request described above:
$ curl -i https://data.staging.perio.do/bags/
HTTP/2 200
server: Fly/e440b950 (2023-09-20)
date: Tue, 03 Oct 2023 23:16:57 GMT
content-type: application/json
content-length: 3
x-cache-status: MISS
x-periodo-server-version: 1.0.0-5-ga495be9
access-control-allow-origin: *
access-control-allow-headers: If-Modified-Since, Authorization, Content-Type
access-control-expose-headers: Last-Modified, Location, Link, X-Total-Count, X-PeriodO-Server-Version
access-control-allow-methods: GET, POST, PATCH, HEAD, OPTIONS
via: 1.0 fly.io, 2 fly.io
fly-request-id: 01HBVX90RPY1NSB9P1RRAN0PNG-iad
[]
Plus, those weird log messages only appear when the health check is enabled.
All indications are that I am operating on incorrect assumptions about the environment within which health checks run—but I don’t know how to correct them.