> For the complete documentation index, see [llms.txt](https://docs.madrix.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.madrix.dev/troubleshooting/performance-and-slowness.md).

# Performance and slowness

Slow UI, slow endpoints, timeouts, or high consumption.

### When to use

* UI slow to load lists and forms.
* API timeouts.
* Slowness only in one environment (e.g., Prod).

### Quick checklist (2 min)

1. Compare Dev vs Staging vs Prod.
2. Test with a “clean” user (without much data).
3. Isolate: is it UI, API, or database?

### Diagnosis

#### 1) Is it client-side or server-side?

* Client-side: high CPU in the browser, heavy rendering.
* Server-side: slow requests in Network, high time-to-first-byte.

#### 2) Data and queries

* Lists without pagination tend to degrade quickly.
* Filters and sorts may require indexes.

#### 3) Integrations

* Do calls to external services block the main request?
* Are timeouts configured?

### How to resolve (patterns)

* **Slow lists**: pagination, mandatory filters, reduce columns.
* **Slow API**: review critical endpoints and queries.
* **Database**: indexes, avoid N+1, review recent migrations.

### When to escalate

* SLA affected in Staging/Prod.
* Abrupt degradation after release.
* Frequent and repeatable timeouts.

Before escalating, gather this evidence. It greatly reduces back-and-forth.

* Project and environment (Dev/Staging/Prod).
* Time of the error (with timezone).
* Steps to reproduce (short and deterministic).
* Full error message (no cropped screenshots).
* Screenshot of the screen (if applicable).
* Browser console (relevant errors and warnings).
* Tab **Network** (request that failed + status + payload, if there is no sensitive data).

{% hint style="info" %}
If there is a `requestId`, `traceId` or execution link, include it as well.
{% endhint %}