Skip to main content

Overview

A clock enforces a service level agreement by tracking elapsed time on an item. Every item is on a clock automatically from the moment it is created. Clocks track elapsed time against a target and flag items that are approaching or past their deadline. Each process sets the expected time-to-close in hours using rules, and the clock calculates how much time remains. Different containers can use different clock configurations. A support container can run 24x7, while a development container runs during working hours only. This is how enterprise customers drive differing service level agreements across the business. Clocks are separate from time tracking. Time tracking records hours worked by people. Clocks track elapsed calendar time against SLA targets.

Clock configuration

You manage clocks under Settings > Clock. Each clock configuration defines working times, days, and non-working days, and can be scoped to specific containers or applied globally.
PropertyDescriptionDefault
NameConfiguration name”Default”
ContainerWhich containers use this clock (select All for global)All
TimezoneTimezone for all clock calculationsUTC
Start of dayWhen the working day begins (HH:MM, 24-hour)09:00
End of dayWhen the working day ends (HH:MM, 24-hour)17:00
Start of weekFirst working dayMonday
End of weekLast working dayFriday
Working clockWhether the clock runs 24x7 or working hours onlyWorking hours only
Non-working daysHolidays and closures in YYYY-MM-DD format
You can create multiple clock configurations. When processing an item, Ekso first looks for a clock that targets the item’s container. If none is found, it falls back to the global clock (one with no container restriction).
Use Working hours only when your SLA is measured in business hours (for example, “respond within 4 business hours”). Use 24x7 when your SLA runs continuously regardless of business hours (for example, a support desk with round-the-clock coverage).

How clocks work

Every item carries four clock fields:
FieldDescription
Clock startWhen the clock started ticking (set automatically on item creation)
Clock finishWhen the item should be completed by (calculated from start + hours + calendar)
Clock hoursThe estimated time-to-close in hours (set via process rules)
Clock deltaHours remaining until the deadline

Start time

The clock starts automatically when an item is created. Start time can only be changed through rules — users cannot edit it directly. If an item is created outside of working hours, the clock aligns to the next working day start.

Finish time

The finish time is calculated by projecting the clock hours forward from the start time, counting only working hours:
1

Align to working hours

If the start time falls before the start of day, it moves forward to the start of day. If it falls after end of day, it moves to the next working day.
2

Count working hours

The system steps through each day, subtracting available working hours from the total. Non-working days and holidays are skipped entirely.
3

Set finish time

When all hours are allocated, the finish time is set. For 24x7 clocks, the full 24-hour day counts. For working-hours-only clocks, only the configured window counts.
Example: If the start time is Monday 9:00 AM, the clock hours are 36, and the clock runs 9 AM–5 PM Monday–Friday, the finish time is the following Monday at 1:00 PM — 36 working hours spread across 4.5 business days.
The finish time is always calculated. Users cannot edit it directly. To change the finish time, adjust the start time via a rule or change the clock hours.

Delta

The delta is the remaining hours until the deadline. Ekso calculates how many working hours have elapsed since the clock started, then subtracts from the total clock hours: Delta = Clock hours − Working hours elapsed A positive delta means time remains. A zero or negative delta means the SLA target has been reached or breached.

Color coding

The clock status is based on the percentage of time consumed, not the absolute delta. Ekso calculates what percentage of the total clock hours have elapsed, then compares against configurable thresholds.
StatusDefault thresholdMeaning
Green0–69% consumedOn time — most of the time budget remains
Amber70–94% consumedWarning — approaching the deadline
Red95–100% consumedBreach — the SLA target has been exceeded or nearly exceeded
The thresholds are configurable per clock configuration:
ThresholdDefaultDescription
Green threshold0%Percentage at which status becomes green (always starts at 0)
Amber threshold70%Percentage at which status changes from green to amber
Red threshold95%Percentage at which status changes from amber to red
Example: An item has 10 clock hours. After 7 working hours have elapsed (70%), it turns amber. After 9.5 hours (95%), it turns red.

Clock processing

Clocks are recalculated automatically every 5 minutes by a background process. This process evaluates all open items across all tenants, applies the appropriate clock configuration, and updates the clock fields. Once an item is closed, its clock is frozen and no longer recalculated. All clock calculations respect the configured timezone. Clock start and finish times are stored in UTC internally but calculated in the clock’s local timezone to ensure working hours align correctly with the business calendar.

Breach notifications

When a clock approaches or exceeds the SLA target, Ekso can send breach notification emails. These use conditional checks on the delta value, so you can configure different notifications at different thresholds — for example, send a warning when the clock turns amber and an escalation when it turns red.

Clock and rules

Rules interact with clocks in two ways:
  • Rules can modify the clock start time — for example, to delay the SLA clock based on item priority or to reset it after a status change
  • Each process sets the time-to-close (clock hours) using rules, which determines when the finish time falls
Rules are the only mechanism for adjusting clock behavior. This keeps SLA tracking consistent and auditable — all changes are driven by configured automation rather than manual overrides.