Usability monitoring helps you review how devices, or Spots, are used. Interpret the results together with the Spot’s status history and usage schedule. The figures for the selected date range in the Statistics table and the calendar periods in the Spot’s Utilization rate summary are separate views.

Open the statistics and select a date range

  1. In the browser navigation, open Assets and content → Assets, devices, tools → Usability monitoring.
  2. Select the Statistics tab.
  3. Select a period from the Statistics for the selected timerange menu above the table. To enter custom dates, select Between dates... and enter the start and end dates in the adjacent Date range field. The calendar picker limits the second date to within six months of the first.
  4. Find the Spot using the search below its column heading, or filter the list using the selection in the Folder column. The folder filter also includes subfolders of the selected folder.
  5. In addition to the percentages, check Hours in use, Hours not in use, Desired in use, Usage schedule and the row’s Date range.

The default search covers one week. The week, month, three-month, six-month and 12-month selections are rolling searches backwards from the present, rather than results for the previous calendar week, month or year. The search extends to the end of today, but calculated data for today is usually not yet available.

The row’s Date range shows the first and last dates of the daily records included. It does not guarantee that data exists for every day between them. Statistics are only visible for folders you have permission to access. Opening a Spot’s own utilization rate history requires permission to access that Spot.

Uptime % is hidden by default. Open the column selector using the columns icon in the table’s header row and select Uptime %. The icon is in the table’s last column; scroll horizontally to the right if necessary.

The Spot’s Utilization rate summary

Open the Spot’s details using its name link in the Statistics table. On the Basic info tab, expand the initially collapsed Utilization rate section. This section is only visible if a usage schedule is assigned directly to the Spot. A schedule inherited solely through a folder or the service does not make the section visible, even if statistics exist for the Spot.

The section’s Day, Week, Month and Year values show the most recently saved utilization percentage for each period type. They do not follow the date range selected in the Statistics table or show the accumulated result for an unfinished calendar period.

  • Day: the most recently calculated daily result. Regular daily processing calculates the previous day.
  • Week: the result for a calendar week from Monday to Sunday. It is generated when Sunday’s daily data is processed.
  • Month: the result for a calendar month. It is generated when the last day of the month is processed.
  • Year: the result for a calendar year. It is generated when the last day of the year is processed.

For example, Sunday is normally processed on Monday, so the result for the completed week is generated then. The summary uses existing daily records: the end of a period does not guarantee that data has been calculated for every day in it.

The summary does not check how recent the result is or display its date. The figure may therefore refer to an older period, for example after a schedule has ended. No data means that no saved result was found for that period type. A saved result with a zero target, however, appears as 0%.

The weekly, monthly and yearly percentages are calculated by dividing the period’s total hours in use by its total target hours and multiplying by 100. They are not averages of the daily percentages. The summary does not show Uptime % or the machine hour meter reading.

There is an important difference in the daily hours model: the saved daily utilization rate is capped at 100%, but active hours above the target are not reduced to the target hours. The weekly, monthly and yearly summaries use the hour totals without a 100% cap. If the only day in a week with a positive target has a target of 8 hours and 20 active hours, the daily utilization rate is 100%, but the weekly summary is 20 ÷ 8 × 100 = 250%. Zero targets on other days do not add to the hour totals. With a directly assigned daily hours schedule, the Statistics table shows 100% for the same week.

Where does the calculation data come from?

Interpreting utilization rates requires the correct target usage time to be defined for the device and its status changes to be recorded correctly. For example, leaving a device marked as active after it has been taken out of production use can distort the results.

Regular daily calculations use the schedule valid on the day in question: first the schedule assigned to the Spot, then the schedule of its own folder, and finally the service-wide schedule. The search does not continue to schedules in parent folders. The start and end dates are included in the validity period. Without an applicable schedule, no utilization rate is generated for the day.

If the schedule has definitions for even and odd weeks, the week used is determined by the calendar week number, rather than the number of weeks since the schedule started. Both calculation methods use the selected week’s own exceptions.

The Usage schedule shown in the statistics indicates the schedule currently in effect; it does not by itself prove which settings were used to generate older hour records. The table’s special handling of daily hours is also based on the Spot’s current directly assigned schedule setting. Changing this setting can therefore change how older hour records are displayed. Assigning schedules is described in How do I define a Spot’s usage schedule?

Usability monitoring and Machine hours are different things. Machine hours records the device’s meter reading. Usability monitoring uses the usage schedule and the Spot’s statuses as its source data: a device marked as active can accumulate calculated usage time even if its physical meter is not advancing.

The browser’s Active status is called In Use on Android and iOS. The status called Ei käytössä in Finnish represents the same status in all these interfaces: Inactive in the browser and Not in use on mobile. The browser’s Faulty status is called At Fault on mobile. Status changes saved on mobile feed into the same server-side status history and utilization calculations.

How is the day’s status determined?

Both calculation methods determine the initial status in the same way. The status following the last status event before the day determines the day’s starting status, even when there are no status changes during the day. During the day, the status changes at the recorded event times.

If there is no earlier event but there are events during the day, the starting status is assumed to be Active. If there are no events during the day and no earlier event is found, the starting status of the first event in the entire history is used. Only if that is also unavailable is the Spot’s current status used. The current status therefore does not generally override an older recorded status.

A normal change to a Spot’s status creates a status history event in the background. However, switching between Inactive and Faulty does not create a separate event. The event log therefore cannot be used to identify every switch between these two statuses. Both count as time not in use in the calculations.

Daily hours schedule

In this calculation method, each weekday is assigned a target number of hours without exact shift start and end times. The number of hours between the start and end times of an exception applying to the day is deducted from the target, down to a minimum of zero. The clock times do not limit the calculation of actual usage. If several exceptions apply to a day, the first applicable exception in the saved order is used.

The start and end dates of an exception’s date range are included. Monthly recurrence applies to the same day numbers of the month, and yearly recurrence to the same day and month numbers. An exception changes the target, not the Spot’s status history.

When the day’s target is greater than zero, hours in use accumulate only from time spent in the Active status during the full day, normally up to 24 hours. Time spent in the Inactive, Faulty and Disabled statuses does not add to this calculation method’s active hours.

When a daily hours schedule is assigned directly to the Spot, the figures in the Statistics table mean the following:

  • Desired in use: the sum of target hours after exceptions for the calculated days in the selected date range.
  • Hours in use: the sum of active hours for those days. This can exceed the target hours.
  • Hours not in use: for each day, 24 hours minus the day’s active hours is calculated. The amount included is capped at that day’s target hours, with a minimum of zero hours. The daily results are added together.
  • Usage-%: Hours in use ÷ Desired in use × 100, capped at 100%.
  • Uptime %: (Desired in use − Hours not in use) ÷ Desired in use × 100, capped at 100%.

Example: the daily target is 8 hours and the Spot is active for 20 hours. Hours in use is 20, Hours not in use is 4 and Desired in use is 8. Usage-% is 100% because the target is exceeded. Uptime % is (8 − 4) ÷ 8 × 100 = 50%. The first percentage compares active hours with the target; the second subtracts the full day’s time not in use from the target, with that time capped at the target hours. Uptime % is therefore not the proportion of active time out of 24 hours.

Zero target: if the day’s target is zero, its hours in use, hours not in use and utilization rate are also saved as zero, even if the Spot is active. The day does not add to the period’s hour totals. If the total target hours for all the data being reviewed is zero, Usage-% is 0% and Uptime % displays a dash.

Time-based schedule

A Time-based schedule defines usage periods by clock time. Desired in use consists of the schedule’s usage periods after exceptions. An end time of 23:59 is treated as the end of the day.

An exception deducts only the time overlapping a usage period: it can remove the period, shorten it or split it into parts. All exceptions applicable to the day are processed. For a multi-day exception, the same time range is processed separately on each day; monthly and yearly recurrence are also taken into account. Overlapping usage periods are merged so that the same time is not counted twice.

The calculation treats every period spent in Inactive or Faulty status as time not in use. Only the portion within the schedule’s remaining usage periods is deducted from scheduled usage time. Consecutive periods in these statuses are also handled: switching between them does not start time in use. Time not in use outside the schedule does not reduce the utilization rate.

Example: scheduled usage is from 8:00 to 16:00, or 8 hours. The device is Inactive from 6:00 to 10:00 and Faulty from 10:00 to 12:00, after which it is active. Time not in use within the schedule is from 8:00 to 12:00, or 4 hours. Hours in use is 4, Hours not in use is 4 and Usage-% is 4 ÷ 8 × 100 = 50%.

The Disabled status is handled differently: it does not itself create time-based periods of non-use. If the status changes from Inactive or Faulty to Disabled, the previous period of non-use ends at the time of the change. After this, scheduled hours can again be counted as hours in use, even if the device is not actually being used. Disabled should therefore not be interpreted as a non-use status in this calculation method.

In the statistics, Hours in use is the sum of scheduled hours remaining after time not in use is deducted. Hours not in use is the difference between target hours and hours in use. Usage-% is Hours in use ÷ Desired in use × 100. When the total target hours is zero, the result is 0%. Uptime % is not calculated with this method, so the column displays a dash.

Time zone and daylight saving time changes

Daily calculations use the service’s time zone. In the time-based model, scheduled clock times are interpreted in that time zone and hours are calculated from actual elapsed time. The exact timestamps of status events are retained; no fixed two-hour offset is added.

During the spring clock change, a scheduled clock time that does not exist is moved forward by the amount of the clock change. If the end time is then the same as or earlier than the start time, the period’s duration is zero. In autumn, when a clock time occurs twice, the first occurrence is used for the start and the second for the end. In Finland, for example, 1:00–4:00 lasts 2 hours on the spring clock-change day and 4 hours on the autumn clock-change day.

The daily hours target and the hours deducted for exceptions remain fixed hour amounts regardless of clock changes. However, there is a limitation in actual time: a fully active day with no events is assigned 24 hours even on a clock-change day. On a day with events, active periods are calculated from the elapsed time between events, but the daily total is capped at 24 hours. The Statistics table’s formula for hours not in use always uses 24 hours. The daily hours result should therefore not be interpreted as a measurement based on the actual length of the day in every clock-change situation.

The period percentage and the limitation of inherited schedules

The percentage in the Statistics table is calculated from the hour totals of existing daily records in the selected date range. It is not a simple average of the daily percentages. In daily hours calculations, active hours above one day’s target can therefore offset another day’s shortfall before the period’s utilization rate is capped at 100%.

There is a discrepancy with daily hours schedules inherited through a folder or the service: daily hours are calculated using the daily hours rules, but the Statistics table selects how to handle percentages based on the Spot’s directly assigned schedule setting. When the Spot has no schedule of its own, the utilization rate can therefore exceed 100%, and hours not in use are calculated as target hours minus active hours and can be negative. Uptime % remains a dash.

The earlier example of 8 target hours and 20 active hours appears with this type of inherited schedule as a utilization rate of 250% and −12 hours not in use. A negative figure does not mean actual negative time not in use. Always check both the schedule’s calculation method and whether the schedule is assigned to the Spot or inherited.

The On target label in the table’s Status column means that the calculated utilization rate is exactly 100%. Other values receive the Out of target label, including values above 100% caused by the discrepancy described above. This label is not the Spot’s operating status.

Filtering by utilization rate and target status uses the uncapped ratio of hours. A Spot used beyond its target can therefore appear as 100% in the table while being excluded by the On target filter. The Out of target filter searches for ratios below 100%, so a row above 100% is also excluded by that filter. Target status filtering can override simultaneous hour and percentage filters. Check the filters separately if necessary.

Rounding and result precision

Active periods in daily hours calculations are rounded to four decimal places in hours. In time-based calculations, usage period durations and the deductions for time not in use are rounded to four decimal places. Saved utilization percentages and weekly, monthly and yearly percentages are rounded to four decimal places. The Spot’s summary displays this precision without mandatory trailing zeros.

The utilization rate in the Statistics table is calculated from the hour totals and displayed to two decimal places. Uptime % and hours in use and not in use are also displayed to two decimal places. Hover over a cell to see a more precise value. A figure rounded to 100.00% on screen may not be exactly 100%, so its target label may be Out of target.

When is data generated, and why can history change?

Daily processing calculates the previous day’s data; the previous day is determined using the service’s time zone. The statistics are not a real-time view of today’s usage. Regular daily processing does not automatically fill in earlier missing days.

No data or a missing percentage does not by itself mean that the device was not used. First check the data’s date range, usage schedule and status history. A missing daily record is not the same as a calculated day with a utilization rate of 0%.

When the timestamp of a saved or deleted status history event is at or before the start of today, the change triggers background recalculation of existing utilization data. Even correcting only the event’s reason can trigger it. Processing can change all the Spot’s existing daily records and previously generated weekly, monthly and yearly results, rather than only the corrected day.

Recalculation following a history correction selects a schedule separately for each day in the following order. Each option must be valid on the day in question:

  1. The Spot’s current direct schedule assignment.
  2. The current direct schedule assignment of the Spot’s own folder.
  3. A schedule linked to the Spot’s schedule history.
  4. The service-wide schedule.

If several historical schedules apply, the one with the most recent start date is selected; if these dates are equal, the more recent creation time decides. An inherited schedule can therefore be used in recalculation even if the Spot has no schedule of its own. Regular daily calculations do not use this schedule history fallback.

Recalculation does not create missing daily records or missing summaries. If no applicable schedule is found for a day, its previous daily record remains unchanged. Schedule history also does not guarantee that the original settings will be restored: a currently valid Spot or folder assignment overrides the history, and the calculation uses the selected schedule’s saved settings. Corrections are described in How do I correct a Spot’s status history?

If usability monitoring has been reset

Resetting utilization deletes the Spot’s previous status history, schedule history and saved utilization results. The current status and current schedule assignments are retained. Resetting therefore does not mean changing the device to Inactive or deleting the Spot.

Monitoring starts again from the reset time. Days before the reset are not recalculated. In the time-based model, only scheduled usage hours after the reset time are included for the reset day. In the daily hours model, the target after exceptions is reduced in proportion to the remaining part of the day, and active time only accumulates from the reset time onwards.

For example, on a normal 24-hour day, a reset at 12:00 reduces an 8-hour daily target to 4 hours. The Statistics table’s formula for hours not in use still uses 24 hours, including on the reset day. Its Hours not in use and Uptime % therefore do not describe only time not in use during the monitoring period after the reset. A weekly, monthly or yearly summary after a reset contains only the daily records generated after it, so it should not be compared with an earlier full period without checking its coverage.

Verify the result before comparing or reporting

  1. Check the selected search period and the row’s Date range. When checking the Spot’s summary, use the corresponding completed calendar period instead of a rolling search.
  2. Open Full history of usage rates from the Spot’s row in the Statistics table. Check the dates, hours in use, target hours and daily percentages. This history shows daily records; verify which days actually have data.
  3. Open the Event logs tab in Usability monitoring and Full history events from the Spot’s row. Check the status change times and statuses for the same period. The latest event in the overview alone is not enough to verify an older period.
  4. Check the schedule’s calculation method, validity, the selected week’s usage periods and exceptions, and whether the schedule is directly assigned or inherited. Calculate the utilization rate from the period’s verified hour totals and account for the percentage cap used in that view.
  5. If the history was corrected, reopen the data after background processing and check the changed days and summaries. Also account for any reset or clock-change day. If the result remains inconsistent, resolve it with support before reporting.

Compare devices over the same date range and check their schedules. A device intended for round-the-clock use and one used only on weekdays are not directly comparable based solely on the number of hours. Viewing and filtering statistics does not change the Spot’s status or history.

For more detailed instructions on reviewing and exporting history, see How do I check the usability monitoring history and export the data to Excel?. Changing statuses is a separate task: How do I change a Spot’s status or disable it?