Configuration is broken for some reason… I am running a performance test against our BYOC edge setup using JMeter. The goal is to validate call capacity under high concurrency. I have 50 threads simulating simultaneous inbound calls via SIP trunks. The Genesys Cloud BYOC edge is version 2.3.1.
When the load hits 30 concurrent sessions, the edge starts returning HTTP 503 Service Unavailable errors. This happens before the Architect flow even processes the call. The error appears in the JMeter response sampler for the initial registration request.
HTTP/1.1 503 Service Unavailable
Content-Type: application/json
{“error_code”: “EDGE_CAPACITY_EXCEEDED”, “message”: “Edge node at 10.0.1.5 has reached max concurrent session limit.”}
I checked the BYOC edge dashboard. The CPU usage is only at 40%. The network interface shows no packet loss. The max concurrent sessions setting in the Genesys Cloud admin portal is set to 100. I expected it to handle 50 calls easily.
Is there a hidden limit per edge node? Or is the JMeter script sending requests too fast? I used a constant throughput timer to keep requests steady. The SIP trunk provider confirms they are sending valid INVITE messages. Any help is appreciated.
Check your JMeter thread group settings. Cause: The BYOC edge likely hits its WebSocket connection limit before the Architect flow engages. Solution: Add a Constant Timer in JMeter to space out call initiations and prevent the edge from rejecting new connections with 503s.
The quickest way to solve this is… actually, don’t just add timers. that masks the real issue. the 503 is likely a state mismatch between your terraform config and the actual edge capacity settings. check your genesyscloud_edge_byoc resource. if max_concurrent_sessions is defined in state but the api rejects it due to license constraints, the edge falls back to defaults which might be lower than expected.
run this to verify:
data "genesyscloud_edge_byoc" "current" {
edge_id = var.edge_id
}
output "edge_limits" {
value = data.genesyscloud_edge_byoc.current.max_concurrent_sessions
}
if the output shows a lower number than your 30 threads, that’s your blocker. also, check if you have rate limiting rules in the flow itself. sometimes the edge is fine, but the flow logic throws a 503 if it can’t find a matching queue within the timeout. disable the queue logic temporarily and hit a direct transfer to isolate the edge vs flow issue.
What’s probably happening here is that a mismatch between the logical capacity defined in your infrastructure-as-code and the physical resource allocation of the BYOC edge instance. While adding timers in JMeter might smooth out the initial burst, it does not resolve the underlying state inconsistency that causes the 503 errors once the threshold is breached.
When Genesys Cloud provisions a BYOC edge via Terraform, the genesyscloud_edge_byoc resource must explicitly align with the licensed concurrent session limits. If the max_concurrent_sessions parameter in your HCL file exceeds the actual capacity allocated to your edge cluster, the API may reject the configuration silently or fall back to a conservative default, leading to unexpected 503s under load.
To diagnose this, first verify the current state of your edge configuration using the Genesys Cloud REST API. Retrieve the edge details using the endpoint GET /api/v2/edges/byoc/{edgeId}. Compare the returned max_concurrent_sessions value against what is defined in your Terraform state file.
If there is a discrepancy, update your Terraform configuration to explicitly set the limit within the licensed bounds:
resource "genesyscloud_edge_byoc" "production_edge" {
name = "Production-BYOC-Edge"
version = "2.3.1"
# Ensure this matches your licensed capacity exactly
max_concurrent_sessions = 50
# Verify the region matches your target deployment
region = "eu-west-1"
}
After applying the changes, run a terraform refresh to ensure the state file is synchronized with the actual Genesys Cloud environment. This ensures that the edge instance is correctly provisioned with the expected capacity before re-running your JMeter test. This approach addresses the root cause rather than masking it with artificial delays.