# Operations

> For the complete documentation index, see [llms.txt](https://docs.lertha.com/llms.txt).
> Any documentation page is available as raw Markdown by appending `.md` to its URL.

> Health, upgrades, backups, and what to look at when something is wrong.

## Health

| Endpoint | Answers |
| --- | --- |
| `GET /healthz` | the process is up |
| `GET /readyz` | the frontend's gRPC health service reports SERVING |

The container health check uses `/readyz`, so a process that is up but not serving is unhealthy
and gets restarted. First boot on an empty database migrates the schema, which the start period
covers.

## Upgrading the core

Bump the four core modules in `go.mod` together, to the versions the matching core CLI release
pins. Run `go mod tidy`, run CI, tag. Schema migrations apply on the next boot. Read the core's
release notes for dynamic-config keys that changed; they live in one function.

Then run the lab's contract against the new build before promoting:

```bash
LERTHA_FLOW_ADDRESS=engine-staging:7233 ./gradlew test --rerun-tasks
```

## Refreshing the UI

```bash
cd ../lertha-ui && pnpm build:server
rm -rf internal/ui/assets && cp -R ../lertha-ui/server/ui/assets/local internal/ui/assets
git -C ../lertha-ui rev-parse --short HEAD > internal/ui/UI_VERSION
```

## Backups

Everything is in the two Postgres databases. Back them up like any other Postgres; a restore is a
full restore of both, then a normal boot. History retention bounds their size.

## Reading the logs

The log is JSON. Two lines at boot about a queue reader and "shard status unknown" are normal:
shards are being acquired while the previous process's leases expire.