Realtime

Without Realtime, your app finds out about a new message when the member asks it to. With Realtime, the server tells the app something changed and the app fetches it.

What it changes

The screens where waiting is most obvious:

• Chat — a message arrives while the thread is open, instead of on the next refresh.
• News feed and activity — new posts and comments appear without a pull, on the main feed and on a member’s profile wall.
• Group discussions — the same, inside each group.
• Notifications — the unread badge updates as it happens.
• Online status — with Live Presence placed, a green dot on the avatar of every member who has the app open. It comes from the connection itself, so your site answers nothing for it.
• BuddyPress and BuddyBoss — messages, notifications, and the activity feed: a new post or reply appears on the main stream, inside a group and on a post’s own page without a pull.

Each of these can be switched off on its own under Memberside → Services → Realtime, which is how a busy site sheds its noisiest source without giving up the others.

What it takes off your server

Without Realtime, every live screen asks your site on a timer whether anything changed. Each question is a full WordPress request, and nearly every answer is “no”. While a member is connected, those timers slow to one check every five minutes — a safety net — and your site only answers when something happened.

Screen open	Requests a minute without Realtime	While connected
Better Messages inbox and one thread	about 36	under 1
Ultimate Member chat inbox and one thread	about 33	under 1
News feed with one comment thread	about 11	under 1
Any other screen, with a notification bell	1.3	0.2

On the Memberside community site, the Better Messages new-message check fell from 7,678 requests in a week to 108 once Realtime was on.

Three more things keep the count down, with or without a connection:

• The app stops checking while it is in the background. When the member returns, each open screen fetches once. Push notifications still reach a member who is not looking.
• A chat inbox stops checking while a thread is open on top of it. It refreshes once when the member goes back.
• After 30 seconds in the background the connection is released, so a pocketed phone does not hold one of your plan’s connections.

How it works

The service carries signals, not content. When something changes, your app receives a short message saying so, and then fetches the actual data from your WordPress site over the normal API.

That is a deliberate design rather than an implementation detail:

• Your content never passes through the realtime service, so it holds no copy of your members’ messages.
• Permissions are enforced by your site, on the fetch, exactly as they are everywhere else. A signal cannot leak something the member could not already read.
• A dropped connection costs freshness, never correctness. The app falls back to refreshing as it would without the service.

Setting it up

1. Choose a plan at Realtime in the builder.
2. Authorise your site — see Authorising a site.
3. Enable the Realtime endpoint group under Memberside → REST API.

Step three is easy to miss. Realtime is an endpoint group like any other, and it is off until you switch it on.

Without Realtime

Your app works the same without the service. Each live screen checks your site on its own timer instead:

Screen	Checks your site every
Better Messages thread	4 seconds, or your Better Messages setting
Ultimate Member chat thread	5 seconds
Chat inbox (Ultimate Member or Better Messages)	6 seconds
BuddyPress messages thread	8 seconds
Comments on a post	10 seconds
News feed, group discussion, BuddyPress inbox	15 seconds
Notification bell and Notifications	45 seconds, or your Ultimate Member - Real-time Notifications setting
BuddyPress notifications	45 seconds
BuddyPress or BuddyBoss activity feed	Never — it loads once and refreshes when a member pulls down

That last row is not an oversight. The activity feed has never checked your site on a timer, and Realtime did not give it one — it only lets new posts arrive without waiting for a pull. So this is the one screen Realtime makes better without there being a polling cost to take away.

That is what happens when:

• The site has no Realtime plan, or Realtime is not authorised.
• The Realtime endpoint group is off under Memberside → REST API.
• Your plan’s connections are all in use. A member who connects past the limit is not refused a screen; their app checks on the timers above until a connection frees up. Members already connected are unaffected.
• The connection drops. The app reconnects on its own and polls meanwhile.

The background and open-thread pauses above apply either way.

Reconnection

Clients reconnect with jitter — a small random delay before retrying — so that a brief service interruption does not produce every app in your community reconnecting at the same instant. Nothing to configure; worth knowing if you are watching your own server logs after an outage.

What it does not do

It does not make your site faster. Every screen still reads from your WordPress install at the same speed. Realtime changes when the app knows to read, not how long reading takes.

If your problem is that screens are slow rather than stale, look at Site Health instead.

When it does not work

Symptom	Cause	Fix
Messages still only arrive on refresh	The Realtime endpoint group is off	Enable it under Memberside → REST API
Realtime works for some members only	Their app is an older build	Rebuild and redistribute
Some members update instantly, others a few seconds late, at busy times	More members are online than your plan connects, so the rest poll	Move to a plan with more connections under Realtime in the builder
It stopped after a while	The connection dropped and is backing off	It reconnects on its own; the app still refreshes normally
The site will not authorise	The handshake was not completed	Authorising a site