Setting the Frequency
Two settings decide how much work a poll creates: how often it asks, and how long it keeps asking.
Where to find it
Architect Panel → Background Messaging:
- Polling — the period and life settings
Architect Panel → Activity:
- Error Log — where a misbehaving callback surfaces
Match the period to the data
Not to what feels responsive. The question is how quickly the underlying thing actually changes:
- A shared queue in a busy team — 15 to 30 seconds.
- A dashboard on a wall — a minute or more; nobody is watching for a change within seconds.
- A count that changes a few times an hour — minutes.
A five-second poll on data that changes twice a day is doing seventeen thousand pointless requests per user per day.
Slower is usually fine
People overestimate how fresh things need to be. Users rarely notice the difference between ten seconds and thirty, and never notice it on a screen they are not staring at.
Start slower than feels right and speed it up only if somebody complains — which is the opposite of how these settings usually get chosen.
The life setting matters more than it looks
It bounds how long a poll keeps running. Without it, a browser tab left open on a forgotten screen polls indefinitely — overnight, over a weekend, over a holiday.
That is a real and invisible load: nobody is looking at the screen and the requests continue. A sensible life means an abandoned tab stops asking.
Think about the abandoned tab
It is the normal case rather than the exception. People open a dashboard, get distracted, and leave it. Multiply that across an organisation and a meaningful share of your polling traffic is screens nobody is watching.
Scope narrowly
A poll covering more than it needs does more work and returns more data. Narrow scope keeps each request cheap, which matters precisely because the request is frequent.
Watch it under real load
Polling is fine in testing with three users and is a different proposition with three hundred. If the application slows at busy times, polling frequency is worth checking early — it is one of the few loads that scales with users signed in rather than with work being done.
Review after go-live
Frequencies get set during development, when nobody knows how the application will be used. Revisit them once real usage exists — usually several can be slowed with nobody noticing.
Worked example
An installation reviewed its polls a month after launch. A dashboard polling every five seconds was moved to sixty, and a poll life was added so tabs left open overnight stop. Polling traffic fell by around 80% and no user reported any difference.
Recommendations
- Match the period to how fast the data changes.
- Always set a life — abandoned tabs are the normal case.
- Start slow and speed up only on complaint.
- Review frequencies once real usage exists.