Live delivery tracking

Live delivery tracking is the rider's marker moving on the customer's map in real time. It is entirely optional — nothing else on the platform depends on it, and on cPanel or most shared hosting it cannot run at all. SixPreflight checks it on its own page, separately from the server score, because it is a choice you make rather than a fault if it is off.

What it actually powers

The rider's app sends a location update to the websocket server. A listener running inside that same process picks it up, queues a job, and that job broadcasts the new position to the customer's app on a channel specific to that order. Two consequences follow directly from that path, and both are easy to get wrong:

A queue worker is required too, because the broadcast happens from a queued job, not directly from the listener. The websocket server running with no queue worker means the rider's marker still never moves, even though every other part of the setup looks correct.

There is no fallback to periodic polling in the codebase — with live tracking off, the customer simply sees the rider's last known position and it does not update again until the next thing that refreshes the page.

What it costs to run

One background process at roughly 60 to 90 MB of memory, essentially no CPU while idle, and a few kilobytes per open connection.

The honest comparison is not "this versus nothing" — it is this versus polling. A map that refreshes over the regular API every few seconds would put a full request through your web server for every customer, every few seconds, all day.

So the real cost is operational rather than financial: two long-running processes to keep supervised, and one websocket proxy rule to add to your web server.

The 15 checks

Its own page covers: the process itself running, the process manager supervising it, the listening socket, the firewall, the proxy rule, the certificate, the credentials, the app keys, the app settings, channel authorization, the client-side target, whether the config cache holds a stale value, the queue, the CDN, and the driver selected.

The live test

A real websocket handshake — the same thing a browser does — reading the first frame back rather than stopping as soon as the connection appears to succeed.

That distinction matters. A wrong application key still completes the handshake successfully, and is only rejected afterward, with the connection closing a moment later. Reading the first frame is what tells "the socket opened" apart from "the socket opened and then refused you".

One run therefore proves four things at once: the port is open, a process answered, the protocol upgrade completed, and your application key was actually accepted.

The step most setups miss

Proxying the websocket paths through your web server. Official documentation tends to skip it, and it is the usual reason live tracking works perfectly on a laptop over plain http and fails for every real customer.

A page served over https cannot open a plain, unencrypted websocket connection. Browsers block it silently, with nothing in the console pointing at the real cause.

The setup guide inside the tool generates every value for your specific install, each with its own copy button, so this step is one paste rather than something to work out from a generic example.

Where to go next

• Reading the report — how a check like this one is scored, and why it stays off the main total
• What it checks — the full list of steps this page sits alongside