Skip to content

Violations

Never lose track of an open issue. Violations give you a live, always-current view of every condition in your operation that needs attention — and they stay visible until the problem is resolved, so nothing slips through the cracks.

How violations work

Violation lifecycle — active until condition resolves

When an alert rule triggers, it creates a violation. Unlike one-time notifications, violations persist until the underlying condition resolves. This gives you a live view of everything that's out of compliance across your workspace.

For example: - A geofence exit violation stays active until the device returns to the zone. - A dwell time violation stays active until the device leaves the location. - An inactivity violation stays active until the device reports a new position.

Violation lifecycle

Every violation follows a lifecycle:

active  →  acknowledged  →  resolved
  1. Active — The condition was detected. The violation appears on the Alerts page and needs attention.
  2. Acknowledged — An operator has seen the violation and optionally assigned it to someone. The underlying condition is still present, but the team knows about it.
  3. Resolved — The condition has cleared. Violations can resolve automatically (the device returned to the zone, the dwell ended) or be resolved manually by an operator.

Acknowledging violations

Click Ack on any active violation to mark it as acknowledged. This signals to your team that the issue is known and being handled. Acknowledged violations stay visible on the Alerts page — they don't disappear until resolved.

Resolving violations

Violations resolve in two ways:

  • Automatically — The system resolves the violation when the triggering condition clears (e.g., a device re-enters a geofence). Most violations resolve this way.
  • Manually — Click Resolve to close a violation that you've handled, even if the underlying condition hasn't changed. For example, you might manually resolve an inactivity alert after confirming the device is switched off for maintenance.

If a resolved violation's condition recurs, the system creates a fresh violation with no acknowledgement history — it's treated as a new incident.

The Alerts page

The Alerts page is your triage workspace. It shows individual violations with:

  • Severity — Visual indicator of the priority level.
  • Asset — The affected device, linked to its history.
  • Rule — Which alert rule triggered the violation, linked to the rule detail.
  • Status — Active, acknowledged, or resolved.
  • Duration — How long the violation has been open.
  • Actions — Ack and Resolve buttons.

Use the filters to narrow by status, severity, or rule type. Click the stat cards at the top to quickly switch between active and acknowledged views.

Notifications

Violations trigger notifications at three points:

  • When a violation is created (notification type: new)
  • When a violation is resolved automatically (notification type: resolved)
  • When an operator acknowledges or resolves a violation manually (notification type: status_changed)

Integrating with external systems

The violation lifecycle is fully accessible via the Tracker API, making it straightforward to integrate with dispatch systems, fleet management tools, or custom dashboards.

Example: driver routing integration

A common pattern is connecting violations to a driver dispatch or task management system:

  1. Listen for new violations via notifications. When a return_to_base or scheduled_return violation fires, your system receives the device ID and rule details.
  2. Acknowledge the violation via the API to signal that your routing system has picked it up, optionally assigning it to a driver or dispatcher: 
    PATCH /api/workspaces/{id}/violations/{violation_id}/acknowledge
{"assignee": "driver-42"}
  3. Add notes as the situation develops — for audit trails or handoff between shifts: 
    POST /api/workspaces/{id}/violations/{violation_id}/notes
{"text": "Driver rerouted, ETA 15 min"}
  4. Resolve manually if the external system handles the issue before the device triggers auto-resolution: 
    PATCH /api/workspaces/{id}/violations/{violation_id}/resolve
{"note": "Confirmed returned via dispatch system"}

The API also supports filtering violations by assignee, status, severity, and rule_type — useful for building dashboards that show only the violations assigned to a particular team or operator.

Key API endpoints

Endpoint Method Description
/violations GET List violations with filters (status, severity, rule_type, assignee)
/violations/stats GET Counts by status and severity
/violations/{id}/acknowledge PATCH Acknowledge a violation, optionally assign
/violations/{id}/resolve PATCH Manually resolve a violation
/violations/{id}/notes POST Add a timestamped note

All endpoints are scoped to /api/workspaces/{workspace_id}/. See the interactive API reference for full request and response schemas.

Questions? Contact Blecon support — we're happy to help.