[Message Delivery] High delay detected: ${receiveDelay}ms. P

Error message

[Message Delivery] High delay detected: ${receiveDelay}ms. Possible network or backend issue.

What it means

Diagnostic console.warn from LegacyRoomManager while processing realtime streamMessage events on the client. For each incoming message it compares the message's server timestamp (msg.ts) with the browser clock (Date.now()) and warns when the difference exceeds 2 seconds. It flags slow delivery (network or backend), but client clock skew produces the same warning even when delivery was instant.

Source

Thrown at apps/meteor/app/ui-utils/client/lib/LegacyRoomManager.ts:187

	streams.push(
		...[
			sdk.stream('room-messages', [record.rid], async (msg) => {
				// Should not send message to room if room has not loaded all the current messages
				// if (RoomHistoryManager.hasMoreNext(record.rid) !== false) {
				// 	return;
				// }
				// Do not load command messages into channel
				if (msg.t !== 'command') {
					const subscription = Subscriptions.state.find(({ rid }) => rid === record.rid);
					const isNew = !Messages.state.find((record) => record._id === msg._id && record.temp !== true);

					// Measure and log message receive delay for messages
					if (msg.ts) {
						const receiveDelay = Date.now() - new Date(msg.ts).getTime();

						// Log warning if delay is significant (>2 seconds)
						if (receiveDelay > 2000) {
							console.warn(`[Message Delivery] High delay detected: ${receiveDelay}ms. Possible network or backend issue.`);
						}
					}

					await upsertMessage({ msg, subscription });
					if (isNew) {
						await clientCallbacks.run('streamNewMessage', msg);
					}
				}

				await clientCallbacks.run('streamMessage', { ...msg, name: room.name || '' });

				fireGlobalEvent('new-message', {
					...msg,
					name: room.name || '',
					room: {
						type,
						name,
					},

View on GitHub (pinned to b2c16d5842)

Solutions

Compare the browser clock against the server clock first - clock skew is the most common cause and makes the warning a false positive
If clocks agree and the warn repeats across many clients, inspect server-side latency: MongoDB slow queries, server load, DDP queue depth
Ignore isolated occurrences after sleep/reconnect; queued messages legitimately measure as delayed
Correlate with server logs at the same timestamps to check whether publication was actually late

Defensive patterns

Strategy: validation

Validate before calling

// Only trust the delay metric after accounting for clock offset
const clockOffset = estimateClockOffsetMs(); // e.g. from a server time endpoint
const receiveDelay = Date.now() - clockOffset - new Date(msg.ts).getTime();
const clockIsTrustworthy = Math.abs(clockOffset) < 5_000;
if (clockIsTrustworthy && receiveDelay > 2_000) {
  console.warn(`[Message Delivery] High delay detected: ${receiveDelay}ms`);
}

Prevention

Keep client machines NTP-synced; treat clock skew above a few seconds as measurement noise
Do not alert on a single warn line - aggregate across users before blaming the backend
Build latency dashboards from server-side timestamps rather than client clocks

When it happens

Trigger: A DDP stream message arrives with Date.now() - new Date(msg.ts).getTime() > 2000: after reconnect when queued messages are flushed, during server overload or slow MongoDB writes, or simply because the client clock is off (VMs, dual-boot, drifted NTP). Only non-command messages with msg.ts are measured.

Common situations: Laptop sleeping and resuming with queued realtime messages; workstations with unsynchronized clocks; server restart processing backlog; large message bursts during load tests; slow networks or websocket reconnect storms.

Related errors

AI-assisted analysis of RocketChat/Rocket.Chat@b2c16d5842 (2026-08-18). Data as JSON: /api/errors/08b1c6b596842642. Report an issue: GitHub.