# Diagnose: infinite transaction names from URL parameters
## The symptom
Thousands of distinct transaction names like `GET /accounts/48291`, `GET /accounts/77123`, each with one event. Dashboards are useless, issue grouping fragments, and span quota burns on cardinality instead of signal.
## The cause
The transaction name includes raw URL parameters. Framework integrations normally parameterize routes (`GET /accounts/[id]`), but this breaks when: the route is not registered with the framework router (custom handlers, middleware), the integration does not recognize the framework, or you name transactions manually with the raw path.
## The fix
Name transactions by route pattern, not by URL:
```python
# instead of request.path
transaction_name = f"{request.method} {request.resolver_match.route}"
```
```js
Sentry.startSpan({ op: "http.server", name: "GET /accounts/[id]" }, () => { /* ... */ });
```
Put IDs and other high-cardinality values in attributes/tags instead, where they are searchable but do not create new groupings:
```js
Sentry.setAttribute("user.id", userId); // searchable, not a new transaction name
```
## Confirmation
In the transaction summary, sort by count of distinct names. A long tail of single-event names with the same shape is the fingerprint. After the fix, the tail collapses into a handful of route patterns.
## Verify
Distinct transaction names drop to roughly your route count, span quota usage falls, and dashboards aggregate meaningfully. In v11 stream mode this matters more, not less: spans are the unit now, and unnamed parameterized spans are just as fragmenting as transactions were.