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

# Check Results

> How DevHelm stores and displays check results — timing, assertions, TLS, and retention policies

Every monitor check produces a result record containing timing data, assertion outcomes, region information, and protocol-specific details.

## Result fields

| Field            | Type     | Description                                         |
| ---------------- | -------- | --------------------------------------------------- |
| `id`             | UUID     | Unique check result identifier                      |
| `timestamp`      | datetime | When the check ran                                  |
| `region`         | string   | Probe region that executed the check                |
| `responseTimeMs` | integer  | Total response time in milliseconds                 |
| `passed`         | boolean  | Whether all `fail`-severity assertions passed       |
| `failureReason`  | string   | Human-readable failure description (null if passed) |
| `severityHint`   | string   | `down`, `degraded`, or null                         |

## Assertion results

Each check evaluates all configured assertions. The result includes per-assertion outcomes:

| Field      | Type    | Description                                           |
| ---------- | ------- | ----------------------------------------------------- |
| `type`     | string  | Assertion type (e.g., `status_code`, `response_time`) |
| `passed`   | boolean | Whether this assertion passed                         |
| `severity` | string  | `fail` or `warn`                                      |
| `expected` | string  | What was expected                                     |
| `actual`   | string  | What was observed                                     |
| `message`  | string  | Human-readable result description                     |

A check is marked as failed if **any** assertion with `fail` severity fails. Assertions with `warn` severity don't cause the check to fail but do record a `degraded` severity hint.

## Protocol-specific details

Check results include protocol-specific data depending on the monitor type.

### HTTP details

| Field                  | Description                            |
| ---------------------- | -------------------------------------- |
| `statusCode`           | HTTP response status code              |
| `responseHeaders`      | Key-value map of response headers      |
| `responseBodySnapshot` | Truncated response body                |
| `responseSizeBytes`    | Response body size in bytes            |
| `redirectCount`        | Number of redirects followed           |
| `redirectTarget`       | Final URL after redirects              |
| `tlsInfo`              | TLS certificate and connection details |

### TLS information

When `verifyTls` is enabled, HTTP check results include:

| Field         | Description                            |
| ------------- | -------------------------------------- |
| `subjectCn`   | Certificate common name                |
| `subjectSan`  | Subject Alternative Names              |
| `issuerCn`    | Issuer common name                     |
| `issuerOrg`   | Issuer organization                    |
| `notBefore`   | Certificate validity start             |
| `notAfter`    | Certificate expiry date                |
| `tlsVersion`  | TLS protocol version (e.g., TLSv1.3)   |
| `cipherSuite` | Negotiated cipher suite                |
| `chainValid`  | Whether the certificate chain is valid |

## Viewing results

### Dashboard

The monitor detail page shows check results in a timeline view with pass/fail status, response times, and assertion breakdowns.

### CLI

```bash theme={null}
devhelm monitors get <monitor-id>
```

### API

```bash theme={null}
curl https://api.devhelm.io/api/v1/monitors/<id>/results?limit=10 \
  -H "Authorization: Bearer $DEVHELM_API_TOKEN"
```

## Retention

DevHelm retains raw check results based on your plan. **Retention is queryable** — your plan determines how far back you can read raw results via the API, dashboard, or SDKs. After your tier's window expires, results are no longer returned by any read path; they are subsequently dropped from storage on the global retention cycle.

| Plan                  | Queryable raw retention |
| --------------------- | ----------------------- |
| Free                  | 90 days                 |
| Starter               | 90 days                 |
| Pro                   | 90 days                 |
| Team                  | 180 days                |
| Business / Enterprise | 180 days                |

Aggregated metrics (uptime percentage, average response time) shown in dashboard summaries are derived from the same window. Daily aggregates are kept longer than the raw window.

If you need to permanently delete a monitor's data on demand (e.g. for compliance), explicitly delete the monitor — that path purges associated data on request and is independent of plan retention.

## Next steps

<CardGroup cols={2}>
  <Card title="Monitoring overview" icon="signal" href="/monitoring/overview">
    How monitors and check flow work.
  </Card>

  <Card title="Incident policies" icon="triangle-exclamation" href="/incidents/policies">
    How check results trigger incidents.
  </Card>
</CardGroup>