Performance Hub LogoPerformance Hub

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_policy_or_grant.

Cause: No additive path allowed them: no enabled Access Policy matched Who AND Where AND When, and no permanent grant or active administrator/integration window covered the door.

Resolution:

  1. Open the member in Users and compare person type, membership status, and synced/custom tags with the policy's Who.
  2. Check that Where includes the door directly, through an Access Scope, or through all facility doors, and that no exclusion removes it.
  3. Check When: Anytime, or at least one active Weekly/One-time window. Ends are exclusive.
  4. Remember policies OR together, but each policy requires Who AND Where AND When. A partial match never grants access.
  5. If appropriate, use a separate permanent grant or administrator window; these remain additive.

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 is off. This happens manually (an admin turned off Access enabled) or automatically (the member was deleted in the integration and the panel shows Removed by integration, or they were soft-deleted).

Resolution: Open the user and turn Access enabled back on — or, if they show Removed by integration, reinstate them in the source system (or decouple the row and enable access manually).

A scheduled policy is not allowing access

Symptom: The app shows future availability or the log has outside_access_time_window; a source window appears Stale or Unmapped; or access changes at an unexpected time.

Resolution:

  1. Confirm the policy is enabled.
  2. Check the same policy's Who and Where before investigating its When schedule.
  3. For a One-time window, compare the attempt with [from, to). The displayed timezone cannot shift the stored instant.
  4. For a Weekly window, check its IANA timezone, local weekday/block, optional active bounds, and daylight-saving transition. Ends are exclusive and overnight blocks must be split.
  5. Use the Access Log's policyId and policyName to verify which named policy was evaluated.
  6. Confirm blockAllAccess, Force closed, user disablement, geofence, and controller status are not taking precedence.

For a separate integration window, also verify logical scope mapping, source revision, source age, and delivery health. Unknown, unmapped, or stale source windows fail closed without removing Access Policy or permanent-grant paths.

Older clients can show Outside hours because the compatibility reason is outside_access_hours; the Access Log and newer clients use outside_access_time_window detail.

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 stays locked for members by design. Block all access at this door sets explicit blockAllAccess and denies every member policy, permanent grant, and Access Time Window.

If the controller is online but stops responding normally, Remotely reboot device (door panel → Configuration → Advanced) restarts it. The door keeps its current lock state and drops offline for a minute or two while it boots.

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 Users record.

Resolution: Find their row in Users 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 Users; or their details are stale.

Resolution:

  1. Check Settings → Sync settings — is the source enabled? Is the specific integration enabled? If the card shows N removals held back for review, a large removal is waiting for an admin to review it.
  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. If the row shows Not synced – duplicate, another record shares the same email or phone. See Duplicate resolution.
  5. Use Sync now to force a pass instead of waiting for the daily full sync.
  6. For Access Time Windows, also inspect source age, revision outcome (updated/idempotent/stale/conflict), and scope_key mapping. A failed fetch must leave the previous snapshot unchanged rather than clearing it.

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 and confirm Auto-unlock is on. Check the Next 14 days preview for when the door should unlock.
  2. With Facility staffed hours, check the facility's staffed and holiday hours in Facility & System Configuration. On a public holiday, On public holidays decides whether the door follows holiday hours, stays locked or ignores the holiday.
  3. With Custom schedule, check the day actually has a time block.
  4. Check whether staff used Lock now: the card shows Locked by staff until HH:MM. Resume schedule puts the schedule back.
  5. Remember schedule changes only take effect after saving, which reloads the controller (typically 10–15 seconds).
  6. Maintenance mode takes precedence — a door on Force closed won't auto-open.
  7. 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 policies/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. Policy and geofence changes are used by subsequent authorisation attempts; app-side settings appear when members' apps next refresh.