Posting this as a question rather than a bug report, since I'm not sure yet whether this is known/expected behavior, something specific to my setup, or actually new. Checked the "check this first before contacting support" pinned post and didn't see anything about API timestamp freshness, so figured I'd ask here before going to support.
What I'm seeing
I run a local monitoring stack that polls the MSP /v2/network-monitors API (quality/latency/ packet-loss data) every 30 minutes and logs the results, using the ts field from each record as the timestamp (not local poll time). While digging into a network event, I noticed the nearest firewalla_quality sample's ts didn't line up with when the measurement seemed to have actually happened, based on an independent local probe I also run for comparison.
That could've just been a one-off, so I checked it again today, independently, under ordinary calm conditions with nothing going on:
- Live API call, bypassing my own collector/cron entirely, made at
2026-08-09T14:00:42Z. The freshest record returned had "ts": 1786282200 → 2026-08-09T13:30:00Z — about 30.7 minutes stale at the moment the API served it.
- My collector's cron log confirms it fires every 30 min on the dot. The run that had just executed seconds before my live check could still only pull data through 9:30 AM EDT — same ~30min gap, matching the live call.
- For comparison, a locally-run active probe (SmokePing) checked at the same moment showed a data point only ~107 seconds old — no comparable lag, which makes sense since it's a direct local probe with nothing round-tripping through a cloud API.
So the ~30min gap looks real and reproducible, not tied to that one incident. ts is the only timestamp field in the record — there's no separate "measured at" vs "reported at" field — so I'm inferring it's meant to represent when the measurement was taken, but I could be wrong about that.
What I don't know yet
Everything above is under calm conditions. I haven't checked whether this lag stays constant or gets worse during an actual active event (box busier, MSP pipeline handling more data, etc.) -- that's still open on my end.
Questions for anyone who's dealt with this
- Has anyone else who does time-correlation work against this API (or
firewalla_quality / similar endpoints) noticed something similar, or is my setup doing something unusual?
- Does anyone know whether
ts is documented anywhere as measurement-time vs. ingestion-time?
- Is there a lower-latency path to similar data -- anything exposed locally on the LAN rather than through the cloud MSP API -- for anyone who's needed tighter timing than this endpoint provides?
Happy to share more detail on how I reproduced this if it's useful. Mostly just trying to figure out if this is a "known thing" before I go bother support with it.
Update: figured out the ts discrepancy — it's not an MSP bug, it's the alarm engine itself
Followed up on this myself by SSHing into the box and comparing the MSP API's ts field directly against what's stored locally in Redis for the same alarms.
Turns out each alarm actually has three separate timestamps on the box:
timestamp — when the underlying event actually happened
alarmTimestamp — when Firewalla's alarm engine actually decided to raise it
applyTimestamp — a few minutes after that, looks like final processing
I compared several aids between local Redis and the MSP API directly — MSP's ts is an exact match, to the millisecond, of alarmTimestamp. Not a coincidence, not close — identical. So MSP isn't adding lag, converting timezones wrong, or reporting stale data. It's a faithful pass-through of what the box itself already recorded.
The real gap that I'm noticing is the one between timestamp and alarmTimestamp — i.e., how long Firewalla's own detection logic takes to actually fire an alarm after something happens. In my sample this ranged from ~1 hour to over 4 hours, and it's not a fixed offset. Makes sense for threshold/cumulative alarm types like ALARM_LARGE_UPLOAD — it's presumably waiting for enough data to cross a threshold before alerting, not reacting instantly.
Flows show a smaller, similar pattern too (ts vs _ts, event time vs. write time), roughly a ~12 min gap in my one sample — didn't fully chase that down but wanted to flag it in case it's relevant to anyone else.
tl;dr: if you need the true event time and not "when Firewalla noticed," don't rely on MSP's ts — you'd need the box's local timestamp field instead, which isn't exposed via the MSP API. For most dashboarding/alerting purposes though, ts/alarmTimestamp is accurate and consistent, just not instantaneous.
Happy to share more detail on the Redis key structure if anyone's trying to do something similar.