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.
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
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
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 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
When you select a group, the right panel splits in two on desktop, stacks on mobile.
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
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
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:
- By param. If the error has a
paramfield (the failing request body field), the group key is<param> <method> <path>. Array indices in the param are normalized:lineItems[0][price]andlineItems[5][price]collapse intolineItems[*][price]. This is the most-specific grouping and catches "this one field is wrong everywhere". - By code. Otherwise, if the error has a
code, the group key is<code> <method> <path>. Catches "this endpoint keeps returning the same error code". - 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
The Health panel reads the same api_request_logs data the 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
Three loops the panel is built for:
- 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.
- 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.
- 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
Workbench introduction
The drawer mechanics, the four tabs at a glance, and how to open the Workbench.
Logs panel
The per-request view: response body, request body, headers. Where you land when you click a log row from a group.
Inspector
Drill into a specific resource and see its logs, events, and the graph around it.
Errors
The error envelope, the full list of errorType and errorCode values, and how to handle them in code.
Events panel
The webhook side: every event your account fired, every delivery attempt, every retry.
Object model
What every prefix means and how the resources fit together.