The following are some frequently asked questions related to SysTrack Sensors.
FAQ
Can a sensor be turned off or disabled?
Sensors cannot be turned off or disabled. They can be hidden from the user interface. Sensors have a built-in function called a decider that works to determine whether they are relevant and should be running on a system. For more information, see Sensor Management.
What is the difference between hiding a sensor and disabling it for the Experience Index?
These are two separate controls:
Hiding a sensor removes it from user-facing surfaces (such as the Overview page, System Checklist, and Self-Help). The sensor continues to run and collect data in the background.
Disabling a sensor for the Experience Index removes its impact contribution to the Experience Index score, but the sensor remains visible and continues to collect data. It is still available in all investigative workflows, System Checklists, Detected Issues, and Self-Help.
You can manage both settings from Configure > Sensor Configuration > Management. Hiding is controlled on the Visibility tab, and Experience Index inclusion is controlled on the Experience Index tab. For more information, see Understanding the Experience Index.
What is the Experience Index and how does it relate to the Health Score?
The Experience Index is a sensor-driven score that measures the percentage of the active time of a user that is free from issues impacting their digital experience. It uses configurable categories and lets you control which sensors contribute and how much impact each sensor applies.
The Experience Index does not replace the legacy Health Score. Both scores coexist. The legacy Health Score continues to use its fixed set of KPIs and appears on the Health page in Resolve.
For more information, see Understanding the Experience Index.
Why does a sensor appear in Reliability Engineering but not in Prevent or Resolve?
Each view answers a different question and covers a different time window, so the same sensor can appear in one view but not in another. These differences are expected and do not indicate missing or incorrect data.
Question | Best View | Time Window |
|---|---|---|
Is the problem happening on this system right now? | Resolve | Current state of the system |
What does the user see on this system right now? | Self-Help | Latest sensor evaluation, updated every 15 seconds |
How many systems are affected right now? | Prevent: Current Issues | Systems that reported sensor results in about the last 10 minutes |
Which sensors have affected systems recently? | Reliability Engineering: Sensors | Today and yesterday, starting at midnight UTC |
Has this issue been occurring over time? | Reliability Engineering: Sensor Scope | Last 24 hours, 7 days, or 30 days, starting at midnight UTC |
How is the issue affecting user experience? | Experience Index | Previous days (same-day data is not available) |
Example
The following example shows how a sensor appears in each view after it triggers and after the issue is fixed:
Time | Resolve | Prevent | Reliability Engineering: Sensors |
|---|---|---|---|
08:00: Sensor triggers | Shown | Shown after the next sensor report from the system | Shown after the next sensor report from the system |
11:00: Issue is fixed | Cleared within about 5 minutes | Cleared after the next sensor report from the system | Still shown (the sensor triggered today) |
Following day | Not shown | Not shown | Still shown (the sensor triggered yesterday) |
Day after | Not shown | Not shown | Not shown |
How To Read Differences Between Views:
What You See | What It Means |
|---|---|
The sensor appears in Reliability Engineering but not in Prevent | The sensor triggered earlier today or yesterday but is not active on any system now. |
Reliability Engineering shows more affected systems than Prevent | Reliability Engineering counts systems affected at any time today or yesterday. Prevent counts only systems where the sensor is active now. Systems that have not reported recently, such as offline systems, are not included in Prevent. |
The sensor is active in Resolve but not yet in Prevent | Resolve shows the sensor results that the system saves every 5 minutes. Prevent updates after the system reports these results. |
The sensor is active in Resolve | The issue is present on that system now. |
The sensor is not active in Resolve | The issue is not present on that system now. If the system is offline, Resolve shows the latest stored snapshot instead of live data (see Offline Resolve). |
NOTE: With default settings, Prevent and Reliability Engineering usually reflect changes within about 10 minutes. You might need to refresh the page to see the latest data. Days are calendar days, starting at midnight UTC. For how the Experience Index handles data, see Experience Index.
Time Window Values
Sensor history in Reliability Engineering is calculated using Coordinated Universal Time (UTC). Therefore, “yesterday” refers to the previous calendar day, from 00:00 to 23:59 UTC.
Depending on your current time and time zone, the selected time window may contain more data than the UI label suggests. For example:
UI Label | Actual Coverage | Possible Duration |
|---|---|---|
Last 24 hours | Previous UTC day + today so far | 24–48 h |
Last 7 days | Previous 7 UTC days + today so far | 7–8 days |
Last 30 days | Previous 30 UTC days + today so far | 30–31 days |
Why is a sensor still active after the issue is fixed?
A sensor can stay active for a short time after the issue is fixed. When a sensor checks data with a query, it keeps the query result for a set period before it runs the query again. By default, this period is 5 minutes. A sensor variable keeps its value for the period set in Retention. To refresh sensor variable values right away, run Read Configuration on the system from the Administration page in Configure.
Why does a sensor not trigger when I expect it to?
Check the following:
The Factory Sensor Kit is the latest version. Many sensor issues are fixed in kit updates.
After the last change to the sensor or a sensor variable, you clicked Update Configuration and the system received the new configuration.
The sensor variable values match the values you expect. A role can override the global value of a sensor variable. For more information, see Variables.
Why does the Experience Index change when the number of systems affected by sensors does not?
The Experience Index and sensor counts measure different things:
Sensor counts show how many systems a sensor affected. The Experience Index applies configured impact minutes when its sensors trigger during active time. Impact minutes are scoring values, not a direct measurement of how long users were affected, so the score and sensor counts do not always change together.
The Experience Index uses only the sensors included in its categories. Sensors can be disabled for the Experience Index and still appear in sensor counts.
The Experience Index uses data from previous days, so same-day sensor activity is not reflected in the score.
For details, see Experience Index.
What does Retention = -1 mean?
A Retention of -1 means SysTrack keeps the value of the variable permanently and never refreshes it.
Retention is how long, in seconds, SysTrack keeps the value of a sensor variable before refreshing it. Set it based on the value type of the variable:
For a constant value, set Retention to -1. The value never changes, so it doesn't need refreshing.
For a dynamic value, such as a SQL query, set Retention to the refresh interval you want, in seconds. For example, a Retention of 500 runs the query again every 500 seconds to update the value.
Why do some Values need quotes and others not? For example, the SCCM Version versus the Chrome version.
This is determined by how the corresponding sensor is written. The SCCM Version is for a sensor that looks directly into the Registry. This type of sensor does not require quotes for a string value. The Chrome Version is for a sensor that is written in SQL to query the SysTrack child database. SQL requires string values to be in single quotes. This is a characteristic of the sensor syntax.
Update Configuration takes about 30 seconds. Is it needed every time or can I save multiple changes and then just run it at the end? Does it push to the Agents or just to the Cloud and wait for the agents to check in over the next 24 hours?
You can save as many changes as you want before you click Update Configuration. Click Update Configuration when you are ready to push the changes you made to the system for implementation.
Sensor definitions are communicated from the SysTrack master to the systems through the Configuration. The purpose of Update Configuration is to apply any changes made to sensors to the Configuration so the systems will receive the changes. After you click Update Configuration, the updated Configuration is stored at the master level and will be applied to the systems at the next time when they check in with the master (within 12 hours by default). If you want the changes to be applied right away (for testing or other purposes), click Update Configuration and then force that update to the systems from the Administration page in Configure using the Read Configuration option.