Container Yard Dwell Time Alarm

Who it’s for

Port operators, container yard managers, freight forwarders, and logistics planners asking “which containers have been sitting in the yard too long?”, “is this asset overdue for pickup?”, “are we about to hit free-time on this container?” — when dwell time is the metric that triggers operational action (demurrage charges, yard rebalancing, pickup escalation).

What it does

Raises a Critical alarm when the watched container has stayed inside the monitored yard for longer than the configured dwell threshold, and auto-clears once the container leaves.

How to set up

The rule has a default dwell threshold (48 hours), so it works as soon as it is installed. Install on a device or asset profile (e.g. Container or Trailer) so every container of that type is covered automatically and any new container added later is picked up without extra setup. Single-container installs are also supported.

This rule reads the portStatus telemetry. Pair it with the upstream template for the self-geofencing case where each container carries its own perimeter:

GPS Tracker Geofencing — Entry, Exit, Presence verified Dmytro Shvaika

Most shared-yard setups instead store the polygon on a yard entity that the containers relate to — for that topology, follow the direct container-to-yard relation example or the fleet hierarchy example in the geofencing docs.

How to customize

• To monitor a differently-named yard or zone — change the Time series key on the presenceStatus argument to match your zone group’s name (e.g. portStatus → terminalStatus, portStatus → depotStatus, portStatus → warehouseStatus).
• To use a different dwellHours attribute name — change the Attribute key on the dwellHours argument to match what your containers or assets already use (e.g. dwellHours → freeTimeHours, dwellHours → maxYardHours).
• To change the dwell threshold used when no per-entity attribute is set — change the Default value on the dwellHours argument (e.g. 48 → 72 for a three-day free-time policy, 48 → 12 for a same-day turnaround target).
• To tune the dwell threshold at runtime without editing the rule — set the value on the entity as a regular server-side attribute. It can be edited directly from a dashboard using Update Multiple Attributes input widget:
  • Per container or asset — set the dwellHours attribute on the container itself. The per-entity value overrides the Default value. Useful when different shippers or cargo types carry different free-time agreements.
  • Per customer (in deployments that use customers) — change Entity type on the dwellHours argument to Current owner, then set the attribute on the customer. Every container that customer owns picks up that value.
  • Tenant-wide — change Entity type to Current tenant, then set the attribute on the tenant. The value applies across every container.
• To make the alarm manual-clear-only — remove the Clear condition. The alarm then stays active until an operator clears it. Useful when the dwell breach needs an explicit handoff or pickup confirmation before being closed.
• To restrict firing to operating hours — in the trigger condition’s Schedule, choose Active at a specific time range (or Custom schedule for different intervals per day). Useful when dwell time is only counted during business hours and weekends or holidays should not contribute. For per-entity schedules, switch to Dynamic mode and source the schedule JSON from an attribute on the container.
• To control where the alarm shows up — toggle the propagation flags under Advanced settings.

See also

For assets where the concern is the boundary crossing itself, not how long the asset stays inside — uses the same geofencing CF but reads the transition event key with an immediate match instead of the continuous presence status key with a duration window:

Vehicle Entered Restricted Area Alarm verified Dmytro Shvaika