API Response Time: Find and Fix Slow Endpoints

Slow endpoints frustrate users, time out integrations and quietly increase infrastructure costs. Yet many teams only notice a problem when a customer complains, and then struggle to say where the time goes. Improving API response time starts with measuring it properly, using percentiles rather than averages, and then breaking each slow request into its parts: database queries, calls to other services, application code and network. This guide explains how to measure response times, find the slowest endpoints, trace where time is spent and apply the fixes that usually make the biggest difference, from query tuning and caching to moving work into the background.

Why averages hide slow requests

An average response time can look healthy while many users suffer. Google's SRE book makes this point in its chapter on service level objectives: most requests can be fast while a long tail of requests is much slower, and most metrics are better thought of as distributions rather than averages (Google SRE book: Service Level Objectives).

Track percentiles instead:

• p50, the median, shows the typical experience
• p95 and p99 show the slow tail that affects a meaningful share of requests
• Maximums help spot extreme outliers but are noisy on their own

Set targets for the percentiles that matter to your users and integrations.

Measure API response time per endpoint

Overall figures mix fast and slow endpoints. Measure each endpoint separately:

• Request count, so you prioritise endpoints that are both slow and busy
• p50, p95 and p99 response times
• Error rates, since failures and timeouts often accompany slowness
• Response sizes, which affect transfer time

Most application performance monitoring tools and many API gateways provide this. If you have none, structured request logs with endpoint, duration and status are a good start.

Rank endpoints by impact

Prioritise by impact, not just by slowness. An endpoint called thousands of times an hour at a p95 of one second may matter more than a rarely used report that takes ten seconds. Multiplying request volume by response time gives a rough measure of total time spent, which helps rank work.

Break down where time is spent

For each slow endpoint, find out where time goes. Distributed tracing and profiling tools can show spans for each part of a request:

• Database queries, including the number of queries per request
• Calls to other internal services or third-party APIs
• Application code, such as serialisation or heavy calculations
• Waiting for resources, such as database connections or thread pools

Without this breakdown, optimisation is guesswork.

Worked example: a slow endpoint breakdown

The table below shows a hypothetical trace of a typical slow request to an order history endpoint. Figures are illustrative.

Part of requestTimeFindingFixWaiting for database connection180 msPool exhausted at peakTune pool size and add a connection poolerOrders query420 msSequential scan on customer IDAdd index on customer ID and created dateLine items queries310 msOne query per order, 40 orders per pageLoad line items in one queryCall to shipping API250 msCalled on every requestCache status for a short periodSerialising response90 msReturns full historyPaginate and return only needed fieldsTotal1,250 ms

In this example, no single fix solves everything, but together they address most of the time. Each fix should be measured after release to confirm its effect, ideally one change at a time so the gain from each is clear.

Fix slow database queries

Database work is often the largest share of response time. Common causes include missing indexes, queries that fetch more rows or columns than needed, and the pattern of running one query per item in a list. PostgreSQL's EXPLAIN ANALYZE shows the actual plan, row counts and timings, but note that with this option EXPLAIN actually executes the query (PostgreSQL: Using EXPLAIN). For statements that change data, the PostgreSQL documentation shows wrapping the analysis in a transaction that is rolled back.

The simplified, untested example below checks a query plan without keeping any changes:

-- Simplified, untested example
BEGIN;
EXPLAIN (ANALYZE, BUFFERS)
SELECT id, created_at, total
FROM orders
WHERE customer_id = 42
ORDER BY created_at DESC
LIMIT 20;
ROLLBACK;

Look for sequential scans on large tables, large differences between estimated and actual rows, and sorts that could be served by an index. Run analysis on a copy of production data where possible, not on the live database during peak hours.

Manage database connections

If requests wait for a database connection, adding more application servers can make things worse. Connection pooling keeps a manageable number of connections open and shares them. Our guide to PostgreSQL connection pooling explains how poolers work and how to size them.

Reduce calls to other services

External calls add latency and risk:

• Cache responses that do not change often, with sensible expiry
• Make independent calls in parallel rather than one after another
• Set timeouts so a slow dependency does not hold requests indefinitely
• Move non-essential calls out of the request path

Move slow work to the background

If a request triggers work the user does not need to wait for, such as sending emails, generating files or syncing other systems, queue it and return immediately. The client can check status later or receive a notification.

Watch application code and memory

Not all slowness is in the database or the network. Heavy loops, inefficient serialisation, repeated configuration loading and excessive logging can all add time. Profilers show which functions consume the most time during a request. Memory pressure matters too: in garbage-collected languages, creating many short-lived objects can cause pauses that appear as random slow requests. Fix the hot spots the profiler shows rather than optimising code by instinct.

Return less data

Large responses take longer to build, transfer and parse. Paginate lists, let clients request only the fields they need and compress responses where appropriate.

Test performance under load

An endpoint that is fast with one user may slow sharply under concurrent traffic. Test with realistic traffic patterns before major releases and after significant changes. Our guide to API load testing explains how to plan and interpret load tests.

Prevent regressions

Once response times improve, keep them there:

• Set alerts on p95 and p99 for key endpoints
• Track response times per release
• Include performance checks in code review for queries and external calls
• Review the slowest endpoints regularly

Frequently Asked Questions

How should API response time be measured?

Measure each endpoint separately using percentiles such as p50, p95 and p99, alongside request volume and error rates, rather than relying on averages.

What usually causes slow API responses?

Common causes are slow or repeated database queries, waiting for database connections, slow calls to other services, large responses and heavy work done inside the request.

Is EXPLAIN ANALYZE safe to run?

It actually executes the query. For statements that change data, wrap it in a transaction and roll back, and avoid running heavy analysis on production at peak times.

How do you stop response times getting worse again?

Alert on high percentiles for key endpoints, track response times per release, review queries and external calls in code review and test under load before major releases.

Make your slowest endpoints fast

We trace slow API requests, tune queries and connections, add caching and background processing, and set up monitoring to keep response times low. See our custom app development services, or talk to us about API performance.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.