Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/No-Country-simulation/G9-LATAM-Team-58/llms.txt

Use this file to discover all available pages before exploring further.

The /health endpoint probes each of Mindloom’s external dependencies — the inference service and the Oracle database — and returns a structured report of their reachability. Each probe runs concurrently on a virtual thread with a hard 3-second timeout, so a hung or unresponsive dependency can never stall the health check itself. Use this endpoint for liveness and readiness checks in your container orchestration layer, or for monitoring dashboards that need per-service breakdown.

Endpoint

GET /health
Base URL: http://localhost:8080
Auth: None required
Query parameters: None

How the status is determined

The overall status field is computed from the probe results as follows:
  • UP — the inference probe is reachable AND (the database probe is reachable OR the database is not enabled)
  • DEGRADED — any other combination
In scaffold mode (no db Spring profile), the database probe is skipped entirely. Its entry in dependencies reports enabled: false and does not contribute to the overall UP/DEGRADED decision.

Response — 200 OK

The health endpoint always returns HTTP 200, regardless of whether the system is UP or DEGRADED. Check the status field in the body to determine actual health.
status
string
required
Overall system status. Either "UP" or "DEGRADED". See the logic above for how this value is derived.
timestamp
string
required
ISO-8601 UTC timestamp recording when the health check was performed (e.g. "2026-07-28T10:32:41Z").
dependencies
object[]
required
Array of per-dependency probe results. One entry per dependency — currently "inference" and "database".

Examples

Request

curl http://localhost:8080/health

Healthy response (UP)

All dependencies are reachable.
{
  "status": "UP",
  "timestamp": "2026-07-28T10:32:41Z",
  "dependencies": [
    {
      "name": "inference",
      "enabled": true,
      "reachable": true,
      "latencyMs": 12,
      "message": null
    },
    {
      "name": "database",
      "enabled": true,
      "reachable": true,
      "latencyMs": 8,
      "message": null
    }
  ]
}

Degraded response (inference down)

The inference probe timed out after 3 seconds.
{
  "status": "DEGRADED",
  "timestamp": "2026-07-28T10:33:00Z",
  "dependencies": [
    {
      "name": "inference",
      "enabled": true,
      "reachable": false,
      "latencyMs": 3002,
      "message": "Health probe timed out after 3s"
    },
    {
      "name": "database",
      "enabled": true,
      "reachable": true,
      "latencyMs": 7,
      "message": null
    }
  ]
}

Scaffold mode response (database not configured)

When the db Spring profile is inactive, the database probe is skipped. If inference is reachable, the overall status is still UP.
{
  "status": "UP",
  "timestamp": "2026-07-28T10:34:10Z",
  "dependencies": [
    {
      "name": "inference",
      "enabled": true,
      "reachable": true,
      "latencyMs": 11,
      "message": null
    },
    {
      "name": "database",
      "enabled": false,
      "reachable": false,
      "latencyMs": 0,
      "message": "Database not configured (scaffold mode)"
    }
  ]
}

Implementation notes

  • Both probes run concurrently on virtual threads via Executors.newVirtualThreadPerTaskExecutor(). A hung probe blocks only its carrier thread and never delays other probes or incoming requests.
  • The database probe executes SELECT 1 FROM DUAL against Oracle to confirm connectivity.
  • The inference probe calls IInferenceClient.isReachable(), which hits the inference service’s own /health endpoint.
  • The executor is shut down gracefully on application stop via @PreDestroy.

Error Codes

The endpoint itself does not return error HTTP status codes — it always returns 200. Dependency failures are communicated via "reachable": false in the dependencies array and a "DEGRADED" top-level status.

Build docs developers (and LLMs) love