The campaign logs are throwing 503 Service Unavailable errors when the predictive engine attempts to allocate calls to our primary BYOC trunks in the Asia Pacific region. This happens despite the trunks showing healthy SIP registration status in the admin console. The issue appears intermittent, correlating with high-concurrency bursts during peak hours. Referencing Predictive Routing Capacity Limits, we are well within the stated thresholds for our license tier. Any insights on whether this is a carrier-side rejection or a platform-side allocation failure?
If you check the docs, they mention that predictive outbound capacity is strictly tied to the concurrency_limits defined in the WFM schedule group, not just the raw SIP trunk health. Even if the BYOC trunks show a green status, the predictive engine will return a 503 if the scheduled agent capacity for that specific time slot is exhausted or if the schedule_group_id mapping is misconfigured.
When publishing weekly schedules for the Chicago team (America/Chicago), I always double-check that the outbound campaign is linked to a dedicated WFM group with explicit max_concurrent_calls settings. Using the default group often causes silent failures where the engine thinks no agents are available, triggering the 503.
Try validating the schedule_group_id in the campaign settings and ensuring the agent_capacity buffer is set to at least 10% above peak demand. Also, verify that shift swaps haven’t inadvertently reduced the available headcount for that specific hour. The API is strict about matching scheduled capacity to actual available agents.
This is actually a known issue… The 503 often masks underlying API rate limits during high-concurrency bursts. Since predictive outbound relies heavily on the platform API for call disposition updates, ensure your integration respects the Retry-After header. Misconfigured retry logic can trigger cascading failures, making healthy trunks appear unavailable. Check the Retry-After value in the response headers.