Hi, How do you measure concurrency usage on your side? Is it number of calls dialing and in-progress? Does the evaluation at the end of the call like creating the summary count as a concurrent line until it's done? Is there a limit for calls in a minute, so I can only make 10 calls in any given minute? Is there some sort of cool-down after a call ends before the concurrent line can be used again? I have an **outbound **system using Vapi to make calls and I'd like to optimise my concurrency. I have a process where I queue calls on my side within the concurrency limit and then make the calls. Any time the call ends I "free-up" a line. When I schedule it for every minute to allocate any unallocated lines it works without issue, but when I schedule it for every 30s or 45s I hit the concurrency limit and get an email from Vapi. Additionally, I have a concurrency limit of 20, but I've limited my process to use a maximum of 18 lines. If I check all the calls as per Vapi, I can see that at no point are there more than 18 calls dialing or in-progress at the same time if I schedule my process for every minute. In the cases where I've increased my schedule I still can't see where it exceeds 18. Note that I have investigated for calls which may be made on the account outside of my process, but in the cases where Vapi sends me the email that I've exceeded the concurrency limit, only calls made by my process were made. The issue I have is that I'm not operating at full concurrency at all times and am underutilising concurrency. It's also not clear to me whether my process which runs every minute is capable of exceeding the concurrency limit, but is unlikely to or whether it would never exceed the concurrency limit.

Vapi measures concurrency by tracking the number of active calls (dialing and in-progress) using a

concurrencyCounter

. Post-call processing like summary generation does not count toward concurrency—only live calls do. To optimize your usage, consider polling Vapi's concurrency status (via API or dashboard) before scheduling new calls, ensuring you never exceed your limit even during rapid scheduling intervals. This approach helps you align your process with Vapi's real-time tracking and avoid unexpected concurrency limit breaches. [See more in the changelog and FAQ.](https://docs.vapi.ai/changelog/2025/1/20) Sources: - [Changelog January 20, 2025](https://docs.vapi.ai/changelog/2025/1/20) - [FAQ](https://docs.vapi.ai/faq)

@User How can I poll the concurrency status via API?

Vapi measures concurrency by counting calls that are dialing, in-progress, and still processing like generating summaries toward your concurrency limit until fully complete. There isn’t a fixed cool-down period, but calls only free up a line once all processing is done. If you schedule calls too frequently for example every 30–45 seconds, you might exceed concurrency due to overlapping call processing, even if the number of active calls looks below your limit. To optimize, stagger call starts, track all call states, and only free lines after full call completion to avoid hitting concurrency limits..

Thanks, had a suspicion the processing at the end of the call might still count towards concurrency. I'll update things on my side and let you know if there are any issues. Appreciate the prompt response.

@Kings_big💫 @flyingemolga Wading in here as I'm dealing with a similar issue - still a little unclear on how to poll the concurrencyCounter via API. Can either of you please share the structure of the query to be made to the analytics endpoint? Assuming that's the right approach. Would be greatly appreciated.

Hi, in my case where I'm only doing outbound calls, I'd say it's best to track concurrency yourself. The issue on my side is that it's possible to have overlapping processes making calls. This means if there's any delay between polling Vapi to get the current concurrency and then making the call, you could have a mismatch if another process has done the same. Additionally, I'm not aware of a full-proof analytics query that can be made to Vapi to get the exact concurrency allowing for post analysis, but can be corrected. You can query the maximum concurrency with a step of a minute or group calls by status and select in-progress, ringing and queues, but neither is exactly what I want and the delay between checking the concurrency and making another call is still problematic. You could consider scheduling your calls instead, I suppose. What I'm doing now is tracking concurrency myself. When I want to make a call I try and allocate a "line". If I can, I make the call. If a call ends without being answered or I otherwise get an end of call report, I unallocate a line. Then I have a scheduled process which runs frequently trying to allocate any unallocated lines. That said, if you have an inbound component, the max concurrency analytics query is probably best.

@flyingemolga Thank you so much for such a detailed response. I'm dealing with both inbound and outbound - hence my quest for a direct analytics query as I need it to potentially re-schedule calls in case of a lack of an open 'line'. The docs mention a concurrencyCounter in the Subscription object but I'm unsure of how to retrieve that information from the subscription table or anywhere else in the API. However, your idea of querying the calls by status and acting accordingly is definitely a useful alternative. Will explore that. Thanks again!

Happy I could help. Just keep in mind that querying by status isn't exactly how Vapi tracks your concurrency, since any post call processing isn't accounted for. Maybe have a closer look at the analytics query for the concurrency metric. I could only manage to get minimum and maximum operations working as opposed to getting the exact concurrency at time of calling the API. Maybe I've missed something.

Hey OP! I have faced this same issue, we have given a cool down of 10 seconds after we recieve the end-of-call webhook event from vapi. We are tracking status-update to update the end call event for the unanswered calls. Any suggestions? @flyingemolga

Hey @flyingemolga, Track concurrency locally using webhooks, avoid relying on Vapi analytics, stagger calls, and keep a buffer below your limit to prevent race conditions..

I have given around 1m cool down period still it failed

Try use webhook-based tracking, poll concurrencyCounter before calls..