# Reliability & maintenance

**hlix recovers by re-deciding, not by remembering.** A project's next step is worked out from its current state every time, so an interrupted run or a missed update costs a fresh decision, never a stuck project. Scheduled maintenance makes sure those decisions happen even when nothing else prompts them. This page describes what that maintenance does and what you can expect to see.

## Prerequisites

None to read this. Nothing here is configured per Workspace; the behavior below applies to every Workspace.

## An idle project costs no compute

A project's [Coding Workspace](/concepts/coding-workspace/) keeps nothing running between jobs. Every task, review and preview build runs in a sandbox of its own that is deleted when the job ends. A terminal or desktop sandbox is deleted 15 minutes after the last open tab stops using it. What a project keeps is its saved environment — one per project, the newest only — so an idle project costs storage, not compute.

Opening a preview never starts a sandbox: each merge's preview is built once and hosted.

## Leftovers are cleaned up

A sandbox is deleted by the job that started it. Automatic cleanup also removes anything a project leaves behind:

- a sandbox whose project no longer exists;
- a project's managed repository after the project is deleted;
- a saved environment whose project is gone, or that a newer one has replaced.

Cleanup only ever removes what it can prove belongs to a deleted or replaced project. When in doubt, it waits for the next pass rather than delete something in use.

**Cleaning up never loses work.** Source lives in the project's repository, never only in a sandbox.

## Stalled projects restart on their own

A project is stalled when it has unfinished work — a cycle in `draft` or `triage` — and nothing in progress: no cycle planning, executing or in review.

Every few minutes, hlix finds stalled projects and asks the [project manager](/concepts/agents/) to decide the next step, exactly as it would after any other event. Because the decision is always made from the project's current state, running it again is always safe. A project that missed an update recovers within a few minutes.

A project with anything in progress is never treated as stalled, however slow that work is.

## Other scheduled maintenance

| What | What it does | How often |
| --- | --- | --- |
| Retention | Expires records past their retention window | Daily |
| Overdue cycles | Moves a cycle that has been executing far too long, and its active tasks, to `failed` so the project manager can retry it | Every 15 minutes |
| Expired previews | Removes preview deployments past their expiry | Hourly |
| Delivery retries | Starts queued work again when a start attempt did not complete | Every minute |
| Cleanup | Removes leftovers, as described above | Every 10 minutes |
| Stalled projects | Restarts stalled projects, as described above | Every 5 minutes |

A large backlog is worked through over several passes rather than one long one. Maintenance runs only inside hlix and cannot be triggered with any customer credential.

## Retention windows

| Record | Kept for |
| --- | --- |
| [Audit log](/security/audit-log/) | 24 months |
| Events (the activity feed) | 6 months |
| Execution logs | 30 days |
| Agent runs | Not pruned |

Execution logs have the shortest window: a task's output is gone after 30 days, while its audit trail and its run record remain.

## When a sandbox image is out of date

Every sandbox starts fresh, so a platform upgrade reaches every new sandbox at once. A saved environment built on an older image is treated as out of date: the next job starts from the current base image instead, and the saved environment is rebuilt in the background.

If a sandbox and the platform ever disagree about how a sandbox is laid out, hlix refuses to run the job rather than proceed with a mismatch that could hang silently. The task fails with a message beginning:

```text
Coding Workspace for project … runs driver layout v…, but this backend implements v…
```

**This is resolved by hlix, not by you:** There is nothing to recreate per project. If a project keeps failing with this message, contact hlix support with a [safe support bundle](/reference/troubleshooting/#safe-support-bundle). Do not delete the project to clear it.

## What hlix does not publish

There is no status page and no uptime commitment. `/health` is a liveness probe, not a status summary — see [Environments & endpoints](/platform/environments-and-endpoints/#the-health-check). This page describes how hlix behaves, not a service-level agreement.

## If something has not recovered

- **A project has pending cycles and nothing running.** Wait a few minutes before escalating. If it is still idle, check the project's activity for a spending-cap pause, and the [approvals](/running/approvals/) queue for a question waiting on you.
- **A cycle went to `failed` with no obvious cause.** A cycle that executed far too long is moved to `failed` on purpose, so the work does not hang. The project manager retries it with the failure as context.
- **`{"available": false, "environmentState": "creating", …}` from the terminal endpoint.** The terminal's sandbox is starting. Poll the same endpoint.
- **A task is slower than usual after a dependency change.** The project's saved environment is being rebuilt; until it is ready, a job installs dependencies from scratch. Later jobs start warm again.
- **`Coding Workspace for project … runs driver layout v…`.** See [When a sandbox image is out of date](#when-a-sandbox-image-is-out-of-date).
- **An execution log you wanted is gone.** Logs are kept 30 days. The audit trail and the run record are kept far longer.
- **A record you expected in the activity feed is missing.** The activity feed is best-effort. Only the [audit log](/security/audit-log/) carries a guarantee.

## Where to go next

| If you want to… | Read |
| --- | --- |
| Understand how hlix decides and runs work | [Platform architecture](/platform/architecture/) |
| See what an idle project costs | [The Coding Workspace](/concepts/coding-workspace/#lifecycle-and-cost) |
| Read the guaranteed record | [Audit log](/security/audit-log/) |
| Work through a specific failure | [Troubleshooting](/reference/troubleshooting/) |

## Next steps

[Platform architecture](/platform/architecture/)
  [The Coding Workspace](/concepts/coding-workspace/)
  [Audit log](/security/audit-log/)
  [Troubleshooting](/reference/troubleshooting/)