Get Help and remote trigger events aren't a red flag on their own
Seeing App Get Help or a Fallback Remote Trigger event doesn't mean something is wrong. It usually means one of two things:
Bluetooth didn't connect, so the driver self-served through Get Help to get in.
The driver prefers this access method over waiting for Bluetooth.
Either way, the driver got in without needing to call for support. That's a working system, not a failing one. It's worth checking only when it becomes a pattern for a specific site, tenant or user, which is covered below.
Passback controls stop the gate being abused
Passback tracks whether a driver is currently inside or outside the car park, and expects entries and exits to happen in the correct order. This stops a driver from using Get Help to trigger the gate repeatedly and let other vehicles in behind them. If a trigger doesn't match the expected sequence, it's flagged, which gives you visibility of the attempt rather than a clean, unnoticed open.
Where to check for a pattern
Go to Access Controller.
Open the Logs tab.
Set the date you want to review.
Filter the Type column to either Driver Remote Trigger or Bluetooth events.
Use this filtered view to investigate further, for example to see which tenant or user is repeatedly using remote trigger events to get around Bluetooth.
Use the Access Events Health report for the bigger picture
Filtering logs is useful for investigating a specific incident. The Access Events Health report gives you the broader view: how your hardware is performing across the site over time, and whether misuse is a one-off or a pattern. Use logs to investigate, and the health report to monitor.
For what counts as a healthy percentage, and why lower-booking sites naturally run lower, see [Bluetooth Access Events Health].