Troubleshooting

Symptom-oriented fixes for the most common Door & Gate Access issues. Each entry follows symptom → cause → resolution. For the meaning of any state or denial reason, see the Reference; for the underlying decision logic, see How access decisions work.

Start with the Access Logs. Almost every "can't get in" report has a denied event in the Access Logs with the exact reason. Search the member's name, look at the most recent denied event, and jump to the matching section below.

A door shows Offline

Symptom: The door card shows Offline, members see "Door offline", unlocks can't be sent.

Cause: The door controller hasn't reported in for more than 5 minutes — power or network is down at the device.

Resolution:

  1. Check the controller has power and its network connection (Ethernet cable / Wi-Fi) — the Hardware Troubleshooting page covers the on-site checks (indicator LEDs, PoE splitter, cabling, SIM/antenna on 4G models).
  2. Open the door's panel → Overview tab to see Status (last seen), IP address, and uptime — a recent "last seen" suggests an intermittent network rather than a dead device.
  3. Power-cycle the controller if needed.
  4. For deeper diagnostics, follow Open in Device Management for advanced configuration.
  5. If several doors went offline at once, suspect the site's network/internet rather than the devices.

While a door is offline, members see support contact details on their dashboard (in the default Smart mode), so they can call you.

A member is denied — "You don't have access to this door"

Symptom: Denied event with reason no_matching_rule_or_grant.

Cause: Neither path allowed them: no access rule matched (wrong person type/status/tags, or outside the rules' operating hours) and no per-user grant covers this door.

Resolution:

  1. Open the member in User Access and check their Person type, Membership status, and tags against the rules in Settings → Access Rules. A common case: their membership lapsed, so the status no longer matches the rule.
  2. Check the time of the attempt against the rules' Operating hours — attempts outside every time block are denied via the same reason.
  3. Check whether the door has a scope or per-door rules override — the door card shows an Override badge. The override replaces facility rules for that door, so a member passing facility rules can still be denied there.
  4. If the member should have access regardless of rules, add a per-user grant (door, scope, or facility-wide) on their panel.

A member is denied — "Your access has been suspended"

Symptom: Denied event with reason access_disabled; the user shows a Disabled badge.

Cause: The user's Access enabled switch is off. This happens manually (an admin turned it off) or automatically (the person was removed in the source system and sync disabled them, or they were soft-deleted).

Resolution: Open the user and turn Access enabled back on — or, if sync disabled them because they were removed at the source, reinstate them in the source system (or decouple the row and enable access manually).

Geofence denials — "Move closer" and friends

Symptom: Denied events with reasons outside_geofence, gps_too_imprecise, or location_unavailable.

ReasonCauseResolution
outside_geofenceThe member's reported position is beyond radius + GPS accuracy + buffer from the pinIf they were genuinely on-site: check the pin placement and radius in Settings → Geofencing (use Test Geofence to simulate their spot). Watch for a pin warning that it's far from the facility's saved address. If the door shouldn't be geofenced at all (e.g. a service entry), use the door's Disable geofence for this door option.
gps_too_impreciseThe phone's GPS fix was worse than the Require GPS accuracy better than threshold (default 100 m) — common deep indoorsHave the member retry nearer a window/outdoors. If it's chronic at your site, raise the threshold slightly.
location_unavailableThe phone provided no location — Location services off, or app permission missing/approximateThe member must enable Location for the app and set it to Precise (the app shows an Open Settings shortcut).

The denied event's detail dialog shows the reported coordinates, accuracy, and distance — invaluable for judging whether the member was actually on-site.

Unlock sent but the door didn't open (Timed out / Failed)

Symptom: Events end in Timed out or Failed rather than Confirmed unlocked.

Cause: The command reached the server but the controller didn't confirm — flaky connectivity at the door, or a device fault.

Resolution:

  1. Check the door's online status and device info (Overview tab). A pattern of timeouts on one door points at its network.
  2. Try an admin Unlock door from the panel while watching the door.
  3. Use Identify device (three beeps) to confirm you're physically at the right controller.
  4. If the relay clicks but the door doesn't release, the fault is in the lock circuit — run the jumper and multimeter tests in Hardware Troubleshooting.
  5. Escalate via Device Management diagnostics if the device is online but not actuating.

Also check Maintenance mode — a door on Force closed ignores member unlocks by design (members see "Under maintenance"), and Block all access at this door denies everyone via rules.

Member can't sign in to the app

Symptom: "No record found" at the Send code step.

Cause: The phone/email they typed doesn't match any User Access row.

Resolution: Find their row in User Access and compare identifiers exactly — a different number format, an old email, or a missing identifier are the usual culprits. Update the row (or have the member use the identifier on file). Remember each row needs at least one of phone/email.

Symptom: "Too many attempts."

Cause: Rate limiting — 5 code requests per hour per contact, plus a network-level limit.

Resolution: Wait it out; the per-contact limit is a security measure and cannot be lifted.

Invitation problems

See the dedicated table in Invitations → Troubleshooting. Quick hits: Send failed → check the address and resend; not included in bulk send → they were already invited, have used the app, lack an email, or lack access.

Synced users missing or out of date

Symptom: A person exists in your member system but not in User Access; or their details are stale.

Resolution:

  1. Check Settings → Sync settings — is the source enabled? Is the specific integration enabled?
  2. Expand Sync activity & troubleshooting and search the person — the skip reason tells you exactly why (missing identifier, decoupled, integration off, etc.). See the skip reason table.
  3. Check the user's Track source updates toggle — a decoupled row never updates from the source.
  4. Use Sync now to force a pass instead of waiting for the nightly reconciliation.

Auto-unlock schedule isn't opening the door

Symptom: The door doesn't latch open during its scheduled window.

Resolution:

  1. Open the door's Schedule tab — confirm Auto-unlock is on and the day actually has a time block (an enabled schedule with no days does nothing).
  2. Remember schedule changes only take effect after saving, which reloads the controller (10–15 seconds; longer if a software update was pending).
  3. Maintenance mode takes precedence — a door on Force closed won't auto-open.
  4. Times are in the facility's timezone — verify the facility's timezone setting if windows fire at odd hours.

An admin changed settings but nothing happened

Symptom: Edited rules/geofence/messages with no effect.

Cause: Settings-tab changes aren't applied until Save changes is clicked in the save bar; navigating away offers to discard them.

Resolution: Re-apply and save. Rule and geofence changes then take effect on the next unlock attempt immediately; app-side settings (app lock, messages, support contacts) appear when members' apps next refresh.

Related pages