> For the complete documentation index, see [llms.txt](https://docs.thornode.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thornode.io/infrastructure/bifrost-api/additional-optimisations.md).

# Additional Optimisations

Use this route when you want a lightweight request for keep-alive and connection warm-up.

The main optimization is not the route itself. The real gain comes from reusing the same persistent HTTP connection to Bifrost instead of opening a new connection for every transaction.

`/healthz` exists as a cheap request you can send on that same connection when you want to keep it active between transaction submissions.

## Why It Helps

* Reduces the chance that your next transaction pays the full connection setup cost
* Lets you keep the client-to-Bifrost connection active without sending a transaction
* Gives you a lightweight probe for reachability on the public listener

`/healthz` does not forward anything to upstream providers. It only checks that Bifrost itself is reachable.

{% hint style="warning" %}
Important

`/healthz` only helps if your client reuses the same HTTP client / connection pool.

If your client opens a fresh connection for every call, `/healthz` does not keep the later transaction connection warm.
{% endhint %}

Recommended pattern:

* Keep one long-lived HTTP client
* Enable normal keep-alive / connection pooling
* Send transactions over that reused client
* Optionally call `/healthz` between bursts when you want to keep the connection active

{% hint style="warning" %}
Important

The public Thor-Gateway listener currently uses an idle keep-alive timeout of about `30 seconds` .

If you want to keep the same client-to-Bifrost HTTP connection open, send a lightweight `GET /healthz` or `HEAD /healthz` roughly every `20-25 seconds` .
{% endhint %}

## Routes

| Route           | Use for                                             |
| --------------- | --------------------------------------------------- |
| `GET /healthz`  | Lightweight keep-alive and reachability check       |
| `HEAD /healthz` | Same as `GET /healthz`, but without a response body |

## GET /healthz

Example request:

```bash
curl https://your-bifrost-endpoint/healthz
```

Example response:

```json
{
  "status": "ok",
  "service": "Bifrost Transaction Proxy"
}
```

## HEAD /healthz

Example request:

```bash
curl -I https://your-bifrost-endpoint/healthz
```

Expected behavior:

* Returns `200 OK`
* Returns no response body
* Useful when you want the lightest possible keep-alive probe


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.thornode.io/infrastructure/bifrost-api/additional-optimisations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.