# Health panel (/en/integrate/workbench/health-panel)
Spot the patterns in your account's recent failures. Errors grouped by root cause, sorted by frequency, with a sample log per group.
The Health panel rolls up every failed API request from the last hour, day, or week and groups them by their underlying cause. Instead of scrolling through a thousand 4xx rows in the Logs panel, you see one row per distinct error group, sorted with the loudest at the top.
Use it after a deploy to catch regressions, before a release to verify everything's quiet, or when a merchant says "things have been weird today" and you want a quick read on what's actually broken.
For the drawer mechanics (open, drag, full-screen), see [Workbench introduction](/integrate/workbench/introduction).
## Open the panel [#open-the-panel]
Click the heart-pulse icon in the dashboard's bottom-right dock. The Workbench opens on the **Health** tab pre-filtered to the last 24 hours.
The dock icon turns orange when your account has recent errors, so a glance at the dock tells you whether it's worth opening at all.
## Filters [#filters]
Two filters at the top:
| Filter | What it does |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Time** | Three options: **Last hour**, **Last 24 hours**, **Last 7 days**. Defaults to last 24 hours. |
| **API endpoint** | Free-text path filter, applied client-side after the groups load. Supports `*` wildcards. The popover shows a hint: "You can also use wildcards, like `/checkout/*`". |
A **Reset filters** link appears next to the filter row when the API endpoint filter is set. The total count on the right (e.g. `12 error groups`) reflects the filtered view.
## Reading the group list [#reading-the-group-list]
The left column is a list of error groups, sorted by count (highest first). Each row carries:
* A mono-spaced error identifier in red. This is what XPay grouped the errors by (see [How grouping works](#how-grouping-works) below).
* A count badge on the right, the number of errors in this group within the time window.
* The HTTP method and path the errors hit (when the group is by code or by param; absent for type-only groups).
* A sample error message from the most recent occurrence, truncated to one line.
Click a row to open the group's detail.
## Group detail: Summary + Logs [#group-detail-summary--logs]
When you select a group, the right panel splits in two on desktop, stacks on mobile.
### Summary [#summary]
The summary panel surfaces the latest occurrence's request body (when present) and two sub-sections.
**Impact**:
| Field | What it is |
| --------------- | ------------------------------------------------------------------------------------------------------ |
| **Occurrences** | The total count plus the resolved time-range label ("in the last 24 hours", "in the last hour", etc.). |
| **Path** | The API endpoint the errors hit. |
| **Source** | "Dashboard" (with the team-member name if available) or the API key flavor. |
**Error Details** (from the most recent occurrence in this group):
| Field | What it is |
| -------------- | --------------------------------------------------------------------------------------- |
| **Type** | The error's `errorType`, e.g. `invalid_request_error`, `api_error`. |
| **Code** | The `errorCode`: the specific identifier, e.g. `resource_missing`, `parameter_unknown`. |
| **Param** | The request body field that triggered the error, e.g. `lineItems[*][price]`. |
| **Status** | The HTTP status the response returned. |
| **IP Address** | The client IP. |
| **Origin** | The `Origin` header value. |
### Logs [#logs]
The right side shows up to 10 of the most recent failed requests in this group as compact rows. Click any row to drill into the full Logs-panel-style detail view (request, response, headers, body, error fields).
## How grouping works [#how-grouping-works]
Two failed requests are placed in the same group when they share the same root cause, even if every other detail differs. XPay picks the grouping key in this priority order:
1. **By param.** If the error has a `param` field (the failing request body field), the group key is ` `. Array indices in the param are normalized: `lineItems[0][price]` and `lineItems[5][price]` collapse into `lineItems[*][price]`. This is the most-specific grouping and catches "this one field is wrong everywhere".
2. **By code.** Otherwise, if the error has a `code`, the group key is ` `. Catches "this endpoint keeps returning the same error code".
3. **By type.** Otherwise, the group key is just the `errorType`. The fallback for errors that lack code or param. Group rows of this type don't show a method or path.
Two consequences worth knowing:
* A single bug in your code that produces the same `param`-level rejection on every line item shows up as one group with a high count, not many small groups.
* An endpoint that fails for two different reasons (one missing field, one bad enum) shows up as two groups, even though they hit the same path.
## Retention [#retention]
The Health panel reads the same `api_request_logs` data the [Logs panel](/integrate/workbench/logs-panel) uses, so it's bounded by the same **30-day** retention. Errors older than 30 days disappear from the view because the source rows are physically pruned.
The Time filter caps at **last 7 days**, well inside the retention window.
## A typical use [#a-typical-use]
Three loops the panel is built for:
1. **Post-deploy regression check.** Open Health, set time to **Last hour**, scan the top of the list. A new group at the top means your deploy started producing a new class of error.
2. **Backlog grooming.** Set time to **Last 7 days**, sort is already by count. The top three groups are usually 80% of your error volume; fix those first.
3. **A merchant-reported issue.** Filter the API endpoint to the surface they mentioned (e.g. `/refunds`), set time to **Last 24 hours**. The list narrows to errors on that exact surface so you can see which group their case fell into.
## Where to next [#where-to-next]
The drawer mechanics, the four tabs at a glance, and how to open the Workbench.
The per-request view: response body, request body, headers. Where you land when you click a log
row from a group.
Drill into a specific resource and see its logs, events, and the graph around it.
The error envelope, the full list of `errorType` and `errorCode` values, and how to handle them
in code.
The webhook side: every event your account fired, every delivery attempt, every retry.
What every prefix means and how the resources fit together.