Webhook vs polling for test execution status updates: which approach scales better?

We’re building a dashboard that displays real-time test execution status across multiple projects (500+ test cases running daily). Currently polling the REST API every 60 seconds but concerned about scalability as we add more projects.

Webhook approach seems cleaner - get notified only when status changes. But I’m worried about reliability in our environment where network interruptions happen occasionally. Polling feels more resilient but generates constant API load even when nothing changes.

Anyone running large-scale test monitoring? What architecture patterns work best for keeping external systems synchronized with test execution state changes?

Don’t forget API rate limiting. Polling 500+ test cases every minute can hit quota limits quickly, especially if you’re also using the API for other operations. Webhooks don’t count against rate limits since Polarion initiates them. We got throttled at 1000 requests/hour during peak testing periods. Monitor your API usage metrics and implement request queuing with priority levels - real-time status updates get higher priority than historical report generation.

Webhook reliability is the key concern. We implemented a retry queue where failed webhook deliveries are retried with exponential backoff - 30s, 2m, 5m, 15m intervals. After 4 failed attempts, we flag it for manual investigation. The webhook endpoint must respond within 5 seconds or Polarion considers it failed. Make sure your receiving service is fast and uses async processing for any heavy operations. We also persist webhook payloads to a database immediately for audit trail and replay capability.

The hybrid approach sounds promising. For the polling fallback, how do you optimize the query to avoid scanning all test cases? Our current approach fetches all executions and filters client-side which doesn’t scale.

We run both approaches in a hybrid pattern. Webhooks for immediate updates (90% of cases), with a fallback polling mechanism every 5 minutes to catch any missed webhook deliveries. The polling only queries for items updated since last successful webhook, using timestamp filtering to minimize load. This gives you real-time updates with guaranteed eventual consistency.