Protected by Red Canary is a valuable status that helps you understand when sensor health, connectivity, or other problems are preventing Red Canary from receiving telemetry. Regular monitoring for sensor issues helps to identify systems that may need attention.
To help you identify potential problems, Red Canary has added a range of features. These allow you to easily see health issues, regularly report on sensors not protected by Red Canary, and more proactively respond to problems:
- Protected by Red Canary means that the sensor in question has sent telemetry to Red Canary within three hours before its last checkin time, or has sent telemetry after its last checkin time.
- Last checkin time is the last time the sensor communicated with Red Canary.
- Last activity time is the last time the sensor sent telemetry to Red Canary.
- The last activity time (shown as Last time data seen when viewing the Endpoint detail page) must be within three hours prior to the last checkin time or later than the last checkin time to be
An endpoint should be marked as protected if the last activity time is no older than 3 hours before its last checkin time, or has occurred after its last checkin time.
In other words, if an endpoint checks in and we haven’t seen data since 3 hours prior to that time, we mark it as unprotected. On the other hand, if an endpoint does not check in but we see data for it, we consider it protected. It’s three hours before, or unlimited after.
Red Canary does not update endpoint protected status retroactively. Rather, the status is updated the next time an endpoint checks in. Even if a sensor stops checking in with Red Canary or has been offline for months, it could still be marked as
is_protected:true as long as Red Canary received telemetry from the sensor since three hours prior to its last checkin time. This is to account for endpoints which may be offline for legitimate reasons.
If a sensor has not sent telemetry since three hours prior to the last checkin time or after, its protected status will change to
is_protected:false. At this point, immediate action should be taken to resolve any sensor issues.
On your Red Canary dashboard, we report the number of sensors that have communicated in the last 72 hours. We also indicate any machines that have communicated in the last 72 hours but have not sent telemetry since three hours prior to the last checkin time or after the last checkin time. This count will be displayed in red, and you can click on it to identify the sensors that are having issues.
Please note that a large discrepancy between a sensor's last checkin time and last activity time may indicate that the sensor is having an issue sending telemetry. If you have any sensors of concern, please open a support ticket.
Using the Filter
You can filter for endpoints protected by Red Canary on the Endpoints page. The filter
is_protected:falsewill list any sensors experiencing issues. Similarly, each individual endpoint page has a tag for “Protected by Red Canary,” showing you the status at a glance.
This query may return more results than you expect, particularly if you have a large number of non-persistent VDI machines in your environment. When using
is_protected:false, we look for all cases where sensors appear to have health issues. This includes devices that may have been spun down or no longer have a sensor installed. As a best practice, regularly decommission endpoints not seen in a set number of days.
You can also narrow the results to sensors recently experiencing issues by combining
is_protected:false with a date-based filter, such as
last_activity_time, or by the filter
state:enrolled to filter out endpoints that have been decommissioned.
We also have an Automate trigger for devices that are not protected by Red Canary. When a device becomes not protected by Red Canary, it can trigger playbooks to notify you so that you can resolve the issue. A sensor will register as not protected if it stops checking in and stops sending telemetry, or if it is checking in but has not sent telemetry since three hours prior to its last check in. Note that decommissioned endpoints are considered not protected by Red Canary, so you may want to set your trigger to look for endpoints that have not been decommissioned.