> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Resource faults

> The active faults array, how codes are deduplicated, and how severity maps onto resource status.

Resources that run work in the background always include `faults`: an array of
active faults, or `[]` when none remain. The singular `fault` field is no longer
returned. Read every entry; more than one code can be active at once. Entries
are ordered by `last_at`, newest first, with a stable order for ties.

See [Resource references](/reference-resolution) for how to fetch the resource
itself.

## The Fault object

Each entry includes `code`, `severity` (`error` or `warning`), `message`,
`details` (an object or `null`), `first_at`, `last_at`, and `occurrences`.
The timestamps identify the first and latest observations in the active series.

`details` is structured context, not a string. Legacy free-form text is
preserved under `legacy_text` inside that object.

A healthy resource:

```json theme={null}
{
  "faults": []
}
```

A resource with one active error:

```json theme={null}
{
  "faults": [
    {
      "code": "START_FAILED",
      "severity": "error",
      "message": "The instance did not reach running.",
      "details": null,
      "first_at": "2026-09-14T03:12:00Z",
      "last_at": "2026-09-14T03:12:00Z",
      "occurrences": 1
    }
  ]
}
```

## Deduplication and occurrences

A repeated observation of the same code on the same resource preserves
`first_at`, refreshes `message`, `details` and `last_at`, and increments
`occurrences` from one. It does not add a second row. A code that recurs after
resolution starts a new series.

## Recovery

A succeeding operation resolves only the codes it owns. An independent error
stays visible and can keep the resource in an error state. Clearing one fault
is not proof that every problem has recovered.

Rows migrated from the previous per-resource error strings carry
`LEGACY_FAILURE_STATE`. The operation that now owns that failure resolves it
the same way it resolves its own codes.

## Severity and status

An active `error` sets `current_state` to `error` on instances, `status` to
`error` on other resources, and `failed` on backups. A `warning` does not by
itself change the lifecycle status.

Two surfaces are warning-only: a certificate challenge's DNS fault never moves
`verified`, and a snapshot-policy fault never moves `enabled` or reports
`error`.

Resolved faults disappear from this array. It is not a history feed, and there
is no public fault-history endpoint.

Service-specific codes and recovery are on the pages that describe those
resources: [compute](/compute), [storage](/storage),
[certificates](/certificates) and [load balancers](/load-balancers).