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
Section titled “Prerequisites”None to read this. Nothing here is configured per Workspace; the behavior below applies to every Workspace.
An idle project costs no compute
Section titled “An idle project costs no compute”A project’s 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
Section titled “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
Section titled “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 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
Section titled “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
Section titled “Retention windows”| Record | Kept for |
|---|---|
| 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
Section titled “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:
Coding Workspace for project … runs driver layout v…, but this backend implements v…What hlix does not publish
Section titled “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. This page describes how hlix behaves, not a service-level agreement.
If something has not recovered
Section titled “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 queue for a question waiting on you.
- A cycle went to
failedwith no obvious cause. A cycle that executed far too long is moved tofailedon 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.- 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 carries a guarantee.
Where to go next
Section titled “Where to go next”| If you want to… | Read |
|---|---|
| Understand how hlix decides and runs work | Platform architecture |
| See what an idle project costs | The Coding Workspace |
| Read the guaranteed record | Audit log |
| Work through a specific failure | Troubleshooting |