What the health check measures
The check calls GET /api/v1/health on this same website. A successful response reports that the Python application answered and its API-key database was reachable. It includes a response timestamp and a request ID. No customer key or payment details are needed.
The health route deliberately does not contact exchange providers. An available API can coexist with an unavailable exchange, a provider that has not been enabled, an expired customer key or a rate limit. Inspect the actual endpoint response when investigating an integration.
Interpret failures correctly
A 404 can mean that the optional API proxy has not been installed. A connection error or 502/503 may indicate a stopped service, proxy problem or inaccessible database. A response from the static website alone is not proof that the optional backend is operating.
The public capabilities route identifies configured provider adapters. Configuration is not a license certificate or an upstream-health guarantee. Market routes remain disabled until the operator completes its provider review and configuration.
Report enough context
When contacting the operator through About, include the endpoint, response code, request ID and approximate UTC time. Remove API keys, Authorization headers and any confidential calculation inputs before sharing a report.
This implementation does not create a persistent per-request status history. A fresh check can describe the current response, while any availability commitment or monitoring history must come from the operator’s actual service agreement and monitoring system.