Mlat doesn’t care what you do with your system clock so ntp or not is irrelevant. It cares about dropped samples on the USB bus.
The stats page reports a snapshot of what the state was, updated every 5 minutes. The current state might have changed since the snapshot.
There were some large internal changes deployed to the mlat system over the last few days which seem to have made the system more sensitive to unstable clocks. From the cases I’ve looked at, the clocks are unstable, it’s mostly a case of the trigger levels being set a little differently to throw out more noise.
FWIW, “clock unstable” means more than 25% of receivers you synchronized with in the last 30 seconds had unstable synchronization - the main cause being multiple outliers more than about 4us out causing a step in the pairing.
(edit: I found a bug that would make the mlat servers use more stringent timing requirements than they should be using; also looking into another bug which may be producing bad estimates of average error; so you may see some improvements over the next couple of days)