# Walk Test for Sensor Partitions

Walk Tests verify that all sensors within a partition are functioning correctly. It is typically used:

* After system installation to confirm proper setup.
* For maintenance or insurance compliance.

{% hint style="danger" %}
During a Walk Test, sensor partitions do not trigger alarms, including those configured as *Always Armed.* Camera partitions **should remain disarmed**, and are not supported by Walk Tests.
{% endhint %}

***

## Perform a Walk Test

{% hint style="danger" %}
You need Site Admin permissions to conduct a walk test. 
{% endhint %}

{% stepper %}
{% step %}
**In Verkada Command, go to All Products > Alarms.**
{% endstep %}

{% step %}
**Select the alarm site where you want to perform the test.**
{% endstep %}

{% step %}
**On the left, click System Status.**

a. In the top right, select **Walk Tests**. From here, you can view or download previous test reports.\
b. In the top right, click **Start Test**.
{% endstep %}

{% step %}
**Walk through the site and activate all sensors, including access controller doors if they are configured as alarm triggers.**

a. Each sensor starts in the **Waiting for a Trigger** state. Once triggered, its status updates in real time.\
b. When all sensors have been triggered, click **End Test**.
{% endstep %}

{% step %}
**To download results, select Generate Report to create a PDF summary.**
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
Walk Test sessions automatically end after 4 hours, unless manually stopped.
{% endhint %}

***

## Success criteria for device events

### Wired and wireless sensors

* A successful event is logged when the sensor is triggered.
* For wireless sensors, the system records both RSSI signal strength and battery level.
* A low battery or a weak signal does not affect success if the sensor triggers correctly.

### Access control (AC) doors

Only a Door Open event is counted as a successful test, even if the door is configured for Door Held Open or Door Forced Open.

### Overall success criteria

* The test is successful when all devices are triggered at least once.
* Any warnings, such as low battery or poor signal, are displayed but do not affect overall success.

***

## Device issues

### Warnings

* Each sensor displays its current status. When a warning is active, it reflects the sensor’s current live state.
* If the warning clears during the Walk Test, it will not appear in the final report.
* If it persists until the end, it is recorded in the report.

This allows users to address issues in real time and prevents temporary warnings from affecting the final result.

**Warnings may appear for:**

{% stepper %}
{% step %}
**Low battery**
{% endstep %}

{% step %}
**Poor RSSI**
{% endstep %}

{% step %}
**Device offline**
{% endstep %}
{% endstepper %}

### Debugging issues

You can click on a device to open the device details page without leaving the Walk Test. From here you can:

* Diagnose issues live using camera context, RSSI trends, hub seen during pairing, and battery status.
* Resolve issues immediately by adjusting sensitivity, re-pairing, muting sensors, adding context cameras, or enabling video verification.

### Overriding sensor states

If a sensor isn’t functioning during the Walk Test, you can manually set its result directly from the Walk Test page:

* Select **Device not working** to mark it for follow-up later.
* Select **Skipped / Didn’t test** if the sensor wasn’t tested.

  <div align="left" data-with-frame="true"><img src="https://2259276529-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNU1He6Uj2tgInV2VdCLQ%2Fuploads%2Fgit-blob-353f1730871ecc6dc67df6cc028191bc0553fa91%2F440a4e19d848ad79a60d6a3f5577e01e1a3ea31b.png?alt=media" alt=""></div>