> ## Documentation Index
> Fetch the complete documentation index at: https://ekso.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Clock

> Enforce SLA targets with clocks — set working calendars, track elapsed time, detect breaches, and send notifications.

## Overview

A clock enforces a service level agreement by tracking elapsed time on an [item](/guide/concepts/items). 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](/guide/concepts/processes) sets the expected time-to-close in hours using [rules](/guide/concepts/rules), and the clock calculates how much time remains.

Different [containers](/guide/concepts/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](/guide/concepts/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.

| Property         | Description                                                 | Default            |
| ---------------- | ----------------------------------------------------------- | ------------------ |
| Name             | Configuration name                                          | "Default"          |
| Container        | Which containers use this clock (select **All** for global) | All                |
| Timezone         | Timezone for all clock calculations                         | UTC                |
| Start of day     | When the working day begins (HH:MM, 24-hour)                | 09:00              |
| End of day       | When the working day ends (HH:MM, 24-hour)                  | 17:00              |
| Start of week    | First working day                                           | Monday             |
| End of week      | Last working day                                            | Friday             |
| Working clock    | Whether the clock runs 24x7 or working hours only           | Working hours only |
| Non-working days | Holidays 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).

<Tip>
  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).
</Tip>

## How clocks work

Every item carries four clock fields:

| Field        | Description                                                                     |
| ------------ | ------------------------------------------------------------------------------- |
| Clock start  | When the clock started ticking (set automatically on item creation)             |
| Clock finish | When the item should be completed by (calculated from start + hours + calendar) |
| Clock hours  | The estimated time-to-close in hours (set via process rules)                    |
| Clock delta  | Hours remaining until the deadline                                              |

### Start time

The clock starts automatically when an item is created. Start time can only be changed through [rules](/guide/concepts/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:

<Steps>
  <Step title="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.
  </Step>

  <Step title="Count working hours">
    The system steps through each day, subtracting available working hours from the total. Non-working days and holidays are skipped entirely.
  </Step>

  <Step title="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.
  </Step>
</Steps>

**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.

<Note>
  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.
</Note>

### 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.

| Status | Default threshold | Meaning                                                      |
| ------ | ----------------- | ------------------------------------------------------------ |
| Green  | 0–69% consumed    | On time — most of the time budget remains                    |
| Amber  | 70–94% consumed   | Warning — approaching the deadline                           |
| Red    | 95–100% consumed  | Breach — the SLA target has been exceeded or nearly exceeded |

The thresholds are configurable per clock configuration:

| Threshold       | Default | Description                                                   |
| --------------- | ------- | ------------------------------------------------------------- |
| Green threshold | 0%      | Percentage at which status becomes green (always starts at 0) |
| Amber threshold | 70%     | Percentage at which status changes from green to amber        |
| Red threshold   | 95%     | 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](/guide/concepts/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.
