Access Control · Troubleshooting guide
A badge is rejected at one door—what should I check?
Trace the credential, access group, door assignment and schedule before replacing the reader.
Draft · Nov 13, 2026 · 4 min read
Editorial review pending. This sample article demonstrates the design; verify model-specific instructions before use.
Before you start
For a recognized badge attempt that does not grant the expected access. This workflow does not override lockdowns or change life-safety wiring.
Find the right troubleshooting path
| What you observe | What to investigate | Next check |
|---|---|---|
| One badge fails at one door | Access assignment or schedule | Compare that person’s group and door access. |
| All badges fail at one door | Door, controller or operating state | Check event history and current door state. |
| Access granted but door stays shut | Physical release issue | Refer the lock and door hardware to the installer. |
Use these observations to narrow the cause; they are not a definitive diagnosis.
Work through the checks
Record one exact failed attempt
Note the door, time, credential holder and observed reader response. Compare the event in Command with what happened at the door. A rejected credential and a granted event followed by a stuck door are different problems and should not be handled with the same fix.
Reference: Card Reader LED Behavior (opens in a new tab)Verify the credential belongs to the intended user
Have the access administrator inspect the credential assignment. Use the reader’s model-specific LED reference; a third-party reader may use different colors. If the reader does not recognize the card at all, check format compatibility before assuming an access-level problem.
Reference: Card Reader LED Behavior (opens in a new tab)Trace group membership to the door
In Access, select the site and review Access Levels. Confirm the user belongs to an access group connected to a level that includes this door. If the level was cloned, verify door associations explicitly: Verkada does not clone the controlled doors with the level.
Reference: Add and Modify Access Levels (opens in a new tab)Check the schedule at the failure time
Review the applicable schedule and any exception for the exact date. Exceptions can change access for holidays or special events. Compare the door’s time zone with the reported timestamp. Make only an approved correction; do not grant unrestricted access merely to prove the badge works.
Reference: Access Level Schedules and Exceptions (opens in a new tab)Repeat a controlled test
Have the person present their own badge during an authorized time window. Record the resulting event and physical outcome. If access is granted but the door does not release, stop changing user permissions and have the installer investigate the physical door system.
Reference: Card Reader LED Behavior (opens in a new tab)
Verify the result
Confirm the intended badge works at the intended door and time, while access outside the approved scope remains restricted. Remove any temporary test assignment after the check.
If the issue remains
Provide the failed event timestamp, door, credential type and the assignment/schedule checks completed. Persistent reader or release problems need the installed hardware model and observed physical behavior.
Official Verkada walkthrough
Watch the official tutorial
Official Verkada tutorial linked from the product documentation. Interface details may differ from your current Command version.
Official documentation
Sources checked November 13, 2026. Monarch’s diagnostic sequence combines these references with practical verification checks. Editorial review pending.
Join the conversation
Share what worked for you, or ask a follow-up. No account needed.
Access administrator
A holiday exception is easy to miss when the weekly schedule looks right.
Service technician
“Granted but still locked” is an important distinction. I would want the event time before making a site visit.