Stuck on a problem and need help troubleshooting a data integrity issue in the Performance Dashboard. The Queue Activity view is reporting -1 for Service Level Percentage on several high-volume queues.
This appears to be a calculation error rather than a configuration failure. The underlying flow logic remains unchanged, and agent performance metrics are stable.
Environment is Genesys Cloud EU West, running the latest release. No API modifications were made during the affected window.
Is this a known reporting bug, or should I check specific queue thresholds?
Check your data source configuration to ensure the Service Level metric is pulling from the correct historical bucket, as -1 often indicates a missing or null value in the underlying dataset rather than a negative calculation.
{
"metric": "service_level",
"data_source": "queue_history",
"aggregation": "average",
"null_handling": "exclude",
"time_window": "last_24_hours"
}
The -1 value typically appears when the system cannot find a valid denominator for the SLA calculation, such as zero offered calls or a misconfigured target. In bulk export scenarios, we often see similar null-handling issues where metadata gaps cause calculation engines to default to error codes. Ensure the queue has sufficient call volume in the selected time window and that the service level target is explicitly defined in the queue settings. If the issue persists, verify the audit trail for any recent changes to the queue’s service level targets or routing rules that might have inadvertently cleared historical data references.
1 Like
{
"metric": "service_level",
"null_handling": "default_zero",
"fallback_value": 0
}
You might want to look at changing the null handling strategy. The -1 often stems from a timeout or incomplete data fetch during high concurrency. Setting a default zero prevents that error state from breaking the dashboard aggregation.
2 Likes
neither of you are looking at the right thing. -1 is the SDK’s explicit flag for data_point_count == 0, meaning the queue had absolutely no offers in that window, not a null handling issue. check your time bucket alignment.
1 Like
yeah, tokentracker is spot on. i’ve seen this exact -1 ghost value pop up in eu-west when the reporting bucket size doesn’t match the flow’s wrap-up code duration. if your bucket is 15 mins but agents are taking 20 mins to wrap up, the data gets orphaned and the sdk returns that flag instead of zeroing it out.
don’t just change the dashboard config. you need to verify the historical data integrity via the api first. run this against the specific queue id to see if the underlying metrics are actually empty or just misaligned:
curl -X GET "https://api.mypurecloud.com/api/v2/analytics/queues/queues/{queueId}/data" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"dateFrom": "2023-10-01T00:00:00.000Z",
"dateTo": "2023-10-02T00:00:00.000Z",
"interval": "PT1H",
"metrics": ["serviceLevel", "offerCount"]
}'
if offerCount is > 0 but serviceLevel is null or missing, it’s a bucket alignment issue. if offerCount is 0, then you’ve got a routing loop or a disabled skill that’s dropping calls before they hit the queue metrics.
i hit this last week during a hybrid migration. the fix wasn’t in the dashboard settings at all. it was in the queue configuration. make sure the “wrap up code” timeout in the queue settings is strictly less than your analytics bucket interval. if you’re using 15-min buckets, set the wrap-up to 12 mins max. anything longer and the data point gets stranded in the next bucket, causing the -1 error in the current one.
also check if you’re using custom service level thresholds. sometimes the default 20s threshold conflicts with custom flow timers, causing the metric to fail validation silently.
just… check the bucket sizes first. saves you hours of digging through architect logs.
1 Like