Polling

What Polling Does

Polling is how a screen updates itself without the user refreshing — the browser asks the server periodically whether anything has changed.

Where to find it

Architect Panel → Background Messaging:

• Polling — the configured polls, their scope and frequency

Architect Panel → Dashboards:

• Explore — dashboards, a common consumer of live updates

What a poll is configured with

• A name.
• A scope — what it covers.
• A default period — how often it asks.
• A life — how long it keeps asking.
• A callback function — what runs to produce the answer.

Where it earns its place

• Shared queues. A work list several people pick from should show what is actually left.
• Notifications and message counts.
• Dashboards left open on a screen.
• Anything two people act on at once, where stale information causes duplicated work.

The cost is multiplied by everybody

The thing to hold in mind. A poll every ten seconds is six requests a minute per user — trivial for one person and, with two hundred people signed in, twelve hundred requests a minute arriving whether or not anything changed.

Polling is a load you choose to add, and it is proportional to your user count rather than to activity.

Most screens do not need it

A form somebody is filling in does not need to update. A report they ran two minutes ago does not either. The honest test: would a person act differently if this were thirty seconds fresher?

If not, it does not need polling, and adding it is load for nothing.

Poll for the notification, not the data

Where you can, poll for something small — a count, a flag saying something changed — and fetch the detail only when it has. That keeps the frequent request cheap and the expensive one rare.

Polling that re-fetches a full dataset every interval is the pattern that causes trouble at scale.

Consider push instead

For genuinely event-driven updates, push notifications avoid the whole arrangement — the server tells the browser when something happens rather than being asked constantly. Polling suits steady updating; push suits discrete events.

The callback is code that runs constantly

Whatever the poll calls runs on every poll for every user. Something inefficient there is multiplied more than anywhere else in the application — keep it tight and make sure what it touches is indexed.

Worked example

A service desk polls the shared queue every thirty seconds, returning only a count and a change marker; the list is re-fetched only when the marker moves. Individual ticket screens do not poll at all, because nothing about them changes while somebody is typing.

Recommendations

• Ask whether anybody would act differently before adding a poll.
• Poll for a marker, fetch detail on change.
• Keep callbacks tight — they run constantly.
• Prefer push for discrete events.

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.