agent's 'top 10 slowest endpoints' list was dominated by admin endpoints nobody uses -- real user paths were buried

agent's 'top 10 slowest endpoints' list was dominated by admin endpoints nobody uses -- real user paths were buried

TL;DR

Rank endpoints by total time consumed (average latency times request count), not by average latency alone, and split admin and internal routes out of the user-facing list. A slow admin export that runs twice a day outranks nothing that matters; a slightly slow checkout that serves millions of requests is where the optimization budget goes. Weight by traffic before you prioritize.

The misleading reading

agent's 'top 10 slowest endpoints' list was dominated by admin endpoints nobody uses -- real user paths were buried

Steps

1. Recompute the ranking with traffic weighting. For each endpoint, compute total time = mean latency x request count over the same window:

SELECT endpoint, COUNT(*) AS n, AVG(latency) AS avg_ms,
       COUNT(*) * AVG(latency) AS total_ms
FROM request_metrics
WHERE day = '[date]'
GROUP BY endpoint ORDER BY total_ms DESC LIMIT 20

Expected: user-facing endpoints with moderate latency but huge volume rise to the top; one-off admin endpoints fall off.

2. Tag endpoints by audience: user-facing, admin/internal, health-check, webhook. Filter the 'slowest' report to user-facing only.

   Expected: a separate short list of genuinely slow user paths that the old list buried.

3. Sanity-check the old top 10: pull request counts for each. Confirm they are low-traffic admin or internal routes.

   Expected: counts in the tens or hundreds per day next to user routes in the millions.

4. Profile the new top entries: traces, query plans, dependency latency for the slow user paths.

   Expected: real optimization targets with measurable user impact per millisecond saved.

5. Keep two lists going forward: 'slowest user paths by total time' for prioritization, and a separate admin list nobody confuses with it.

   Expected: the next agent report optimizes what users feel.

Use this when

• A profiler agent hands you a 'slowest endpoints' list and the top entries look unfamiliar or internal.
• Optimization work keeps landing on endpoints with no user traffic.
• You need to decide where profiling effort pays off.

Not for this skill when

• The slow endpoints ARE the high-traffic user paths (then the list was right; profile them).
• You are doing capacity planning for admin tooling itself (then the admin list is the point).
• Latency is uniform and the real problem is throughput or errors, not endpoint speed.

Variant phrasings

slowest endpoint report is all internal tooling

The ranking ignored traffic weight.

agent optimized an endpoint with 12 requests a day

Average latency ranked it; nobody uses it.

top slow queries are all from the admin panel

Split the report by audience before prioritizing.

Why it happens

Ranking by average latency answers 'which endpoint is slowest per request', but engineering time should go to 'which endpoint wastes the most user time'. Those are different questions. Admin exports, report builders, and backfill endpoints are slow by nature and rare by design, so they dominate any unweighted slowness ranking while the merely sluggish checkout that serves all revenue sits at row 47.

Edge cases

• Webhooks and partner callbacks can be high-volume AND slow; keep them in their own list so they neither bury user paths nor get ignored.
• Health-check endpoints with artificial latency (deep checks) pollute every ranking; exclude them everywhere.
• A rarely-hit endpoint that blocks deploys or on-call work can still deserve attention; traffic weight is the default, not a law.
• If route names are not tagged by audience, the tagging step is the real work; do it once in the router or the metrics pipeline.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-VCu-1pwV3cCIAOp1CnF7w