---
id: platform/incident-report
title: Capture an incident report
description: Collect one service's deployment context, paginated logs, and metrics into a local inspectable report with explicit incomplete sources.
keywords: [bex, incident, logs, metrics, troubleshooting, support]
last_updated: 2026-09-23
---

Diagnose a Bex application by gathering **authorized read-only** evidence for one
service and time window. The downloadable collector follows the same log
continuation contract as [Logging](./logging.md) (page size up to 100,
`hasMore` / `nextStartTime` / `nextEndTime`) and treats missing metrics as
unavailable — never as zero usage.

Evidence pin: Bex `7b049538cb0e4784b4daac8ef62b4935c810a6c4`. Fixtures prove
client behavior; they are not evidence of a particular deployed API revision.

## Download and fixture first run

```bash
curl -fsSLO https://bex.co/examples/incident-report-latest.zip
curl -fsSLO https://bex.co/examples/incident-report-latest.zip.sha256
shasum -a 256 -c incident-report-latest.zip.sha256
unzip incident-report-latest.zip
cd incident-report
npm test
BEX_INCIDENT_FIXTURE=1 BEX_OUT_DIR=./out/demo BEX_PAGE_LIMIT=100 node collect.mjs
npm run demo
```

The success fixture walks **more than 100** log lines across pages while
preserving RFC3339 nanosecond cursors. Other scenarios cover empty logs,
unavailable metrics (`503`), and denied access (`401`).

## Authorized live collection

Provide an already-authorized bearer token (see [API](./api.md)). Do not put
tokens in shell history files you will share.

```bash
export BEX_API_ORIGIN=https://api.bex.co
export BEX_ACCESS_TOKEN=…
export BEX_SERVICE_ID=svc_…
export BEX_START_TIME=2026-07-05T00:00:00.000000000Z
export BEX_END_TIME=2026-07-05T01:00:00.000000000Z
export BEX_OUT_DIR=./out/incident
node collect.mjs
```

Optional `BEX_DEPLOY_ID` loads that deploy under the same service. The command
only issues `GET` requests and refuses to follow cross-origin redirects with
credentials.

## Interpreting the output

| Manifest status | Meaning |
| --- | --- |
| `complete` | Required reads finished; metrics are `ok` or intentionally `empty` |
| `partial` | Logs or metrics stopped early or a source was unavailable/denied |
| `incomplete` | Hard failure, cancellation, or deadline — do not treat as success |

`REPORT.md` lists chronology by **exact** timestamp strings. Application log
bodies are literal untrusted content — review before sharing outside your team.
Tokens never appear in written files.

Exhausting accessible log pages does **not** prove retention covers the whole
incident. Correlate [deployments](./how-deploys-work.md),
[health checks](./health-checks.md), and [metrics](./metrics.md) separately when
sources disagree.

## Related

- [Logging](./logging.md)
- [Metrics](./metrics.md)
- [API authentication](./api.md)
- [How deploys work](./how-deploys-work.md)