What actually triggers a notice
A congestion notification looks simple from the outside — the road slowed down, so somebody was told. The useful detail is in what the system refused to send.
Each camera is scored continuously for three things: how many vehicles are passing, how long the queue is, and how fast traffic is moving. Those produce a state for the segment — free, light, moderate, heavy or jam. A change of state does not raise anything on its own. The new state has to hold for a configured period first.
That hold is the whole design. Traffic is naturally noisy: a signal cycle, a lane change, a delivery van stopping briefly. Without a hold, every one of those produces a message, and the channel is muted inside a week.
What the notice contains
A congestion alert that says "TPK_GG04 is congested" forces the recipient to go and look something up, which is where the minutes go. The message should be sufficient on its own:
- Which corridor and which segment, named the way the operations floor names it — not just a camera ID.
- The state and how long it has held, so the reader can tell a building queue from a settled one.
- Direction, because a northbound jam is a different dispatch decision from a southbound one.
- Measured queue and average speed, which is what turns "heavy" into something actionable.
- What has already been done — who else was notified, and whether a sign has been posted.
Who gets told, and when
Different people need the same event at different thresholds. A maintenance crew may only care about a sustained jam; a duty supervisor wants heavy and above; a public subscriber list wants the corridor-level summary and nothing else.
So routing is per rule and per group, and each group carries its own schedule: the hours it has actually asked to hear from you, quiet hours that hold routine notices into a digest, and block-out windows for planned work. A resurfacing project that is already known should not generate a week of overnight alerts.
The exception is deliberate and narrow. Wrong-way detections and watchlist matches ignore those windows entirely. Because that override exists and is limited to genuine safety events, everything else can be scheduled honestly — and a member who trusts the schedule is a member who has not muted the channel.
How this shortens a response
The value is not the alert; it is what happens in the minutes after it. In practice a good congestion notice changes four decisions:
| Decision | What changes with a timely, specific notice |
|---|---|
| Dispatch routing | Responders are not sent into the back of the queue they are meant to be clearing. |
| Public information | A sign or advisory goes out before drivers commit to the corridor, rather than after. |
| Crew scheduling | Planned works are held or moved when the corridor is already degraded. |
| Escalation | A queue that keeps growing after the first notice is visibly a different event from one that is clearing. |
Note what is not on that list: clearing the road. Software tells you what is happening and who should know. It does not move a vehicle, and any claim otherwise should be treated with suspicion.
Managing false positives honestly
Every detection system produces wrong answers, and the ones that pretend otherwise are simply hiding them. Two failure modes matter for congestion.
The first is a miscalibrated detection zone — a polygon that has drifted, or one that is counting a stationary object. It produces a segment that looks permanently busy. Auditing each zone against its own behaviour catches this: constant activity all day, one class dominating, and almost no track diversity is not a busy road.
The second is a genuine slowdown that does not matter: a scheduled event, a market day, a known school-run pattern. That is a tuning problem, not a detection problem, and it is solved with per-day-of-week alerting hours rather than by raising the threshold until real events are missed too.
What to tune before you turn it on
The mistake we see most often is enabling notifications on day one and tuning afterwards, in production, on a duty phone. Run the detection for a fortnight with alerting off, look at what would have been sent, and answer three questions: how many notices per shift would this have produced, how many describe something a person would have acted on, and which recurring pattern is generating noise.
Tune against that, then turn the channel on. An alerting system earns its credibility in the first month and rarely gets a second chance at it.