> For the complete documentation index, see [llms.txt](https://docs.algenta.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.algenta.ai/engine-runtime/health.md).

# Engine health & verification

Confirm that the API, dependencies, and bundled compute runtime are healthy through supported HTTP probes.

Algenta starts and supervises its bundled runtime as part of the deployment. Health checks verify that integrated service; they are not instructions for managing a second process.

## Health endpoints

| Endpoint                   | Authentication | Tells you                                                             |
| -------------------------- | -------------- | --------------------------------------------------------------------- |
| `GET /v1/health`           | none           | API process liveness.                                                 |
| `GET /v1/health/ready`     | none           | Readiness of critical dependencies. A database failure returns `503`. |
| `GET /v1/infrastructure`   | API key        | Executes a compute probe and reports node status and runtime mode.    |
| `GET /v1/runtime/manifest` | API key        | Lists the runtime modules included in this deployment.                |
| `GET /v1/libraries/health` | API key        | Runtime-library health when that optional HTTP surface is enabled.    |

## Compute probe

```bash
curl -sS "$ALGENTA_API_URL/v1/infrastructure" \
  -H "Authorization: Bearer $ALGENTA_API_KEY"
```

The current contract reports:

| Field                                                                  | Healthy value                                                | Failure value                                                            |
| ---------------------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------ |
| primary node `status`                                                  | `live`                                                       | `error`                                                                  |
| `engine_mode`                                                          | `binary`                                                     | `binary` when the probe failed, or `missing` when the artifact is absent |
| `engine_version`                                                       | the executing runtime version                                | `unknown` when the probe fails                                           |
| `probe_latency_ms`                                                     | measured latency of this probe                               | `null` when the probe fails                                              |
| `uptime_30d_pct`, `avg_latency_ms`, `p95_latency_ms`, `throughput_rpm` | `null`; historical metrics require an external metrics store | `null`                                                                   |

`engine_mode: "binary"` means the bundled compiled runtime is present; `status: "live"` proves it executed the probe successfully. Treat both fields together as the readiness signal.

## End-to-end smoke test

```bash
curl -sS -X POST "$ALGENTA_API_URL/v1/simulate" \
  -H "Authorization: Bearer $ALGENTA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"mode":"auto","scenario":{"variables":{"demand":{"low":80,"high":120}},"objective":"maximize_margin"},"runs":100,"seed":7}'
```

A successful response contains real summary statistics. Use repeated requests to evaluate warm performance; do not mix image download, service boot, or the first connection into a hot-path latency measurement.

## Failure handling

The production deployment fails closed when its required compute runtime cannot execute. It must not silently route to a Python implementation. If the infrastructure probe reports `missing` or `error`:

1. Confirm the deployment uses a current signed Algenta image or package.
2. Inspect the API startup logs for the first runtime verification or compute error.
3. Redeploy the same integrated service after correcting the artifact or platform mismatch.
4. Rerun both the infrastructure probe and deterministic simulation.

Do not install or operate an additional runtime service beside Algenta.

## Related

{% content-ref url="/pages/yhNYrVe9zjfJTh9Jj7Pl" %}
[Verify the bundled engine](/engine-runtime/bundled-runtime.md)
{% endcontent-ref %}

{% content-ref url="/pages/70qQAu9mBa5YatEkZbKV" %}
[Monitoring & observability](/deploy-and-operate/monitoring.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.algenta.ai/engine-runtime/health.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.