> For the complete documentation index, see [llms.txt](https://help.security.gallagher.com/knowledge-hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.security.gallagher.com/knowledge-hub/products/cc-software/configure/command-centre-fatigue-management-vs-r.md).

# Fatigue management vs regulated zones

{% hint style="info" %}
**Fatigue Management** and **Regulated Zones** are the same customisation under two names. They manage how long a cardholder may spend on site or in parts of the site.
{% endhint %}

**Fatigue Management** was the original name (introduced v7.10). It was renamed to **Regulated Zones** in v7.30. New work uses Regulated Zones. The only practical difference between the two is the name and the licensing string.

## The rename

Fatigue Management was introduced in v7.10, then renamed in v7.30 to Regulated Zones. Both do the same thing: manage cardholder time on site, or in parts of the site.

|                       | Fatigue Management                                                                                                                  | Regulated Zones                                                                                                                    |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **Available version** | v7.10 to v7.20                                                                                                                      | v7.10 or later                                                                                                                     |
| **Licensing string**  | <p><code>\[Limits]</code><br><code>Fatigue Zones=1</code><br><code>\[Customisations]</code><br><code>FatigueManagement=1</code></p> | <p><code>\[Limits]</code><br><code>Regulated Zones=1</code><br><code>\[Customisations]</code><br><code>RegulatedZones=1</code></p> |

If a site's licence still carries the `FatigueManagement=1` customisation string, it predates the v7.30 rename. The current string is `RegulatedZones=1`. The capability is the same; only the name and licence string changed.

## How it works: monitoring mechanics

A **Regulated Zone** item is separate from, but potentially encompasses, one or more Access Zones. It works with core Command Centre alarm monitoring and control to help ensure the health and safety of employees or contractors on site, managing cardholder time on site. Supported in v8.10 to v9.40 (every version).

### Monitoring parameters

* **Cumulative Duration**: accumulated time on site across multiple shifts. An event raises when a cardholder exceeds the configured cumulative shift duration within a specified period.
* **Break Duration**: minimum break period between shifts. An event raises if a cardholder re-enters within the minimum break period. A configurable temporary exit grace period defines how long a cardholder may be off-site before being considered "between shifts."
* **Maximum Duration**: time on site within a single shift. An event raises if exceeded.
* **Predictive Cumulative Duration**: predicts whether a cardholder, if they stayed for their expected shift duration, would end up at or above the cumulative limit, raising a predictive alarm if so.

### Reporting and notification tools

An **Activity Report** on fatigue events (all or specific cardholders, over a period); a **Notifications Filter** to notify cardholders when a fatigue event occurs (Notifications is a separately licensed feature); a **Site Configuration Report** (Command Centre Classic) on a Regulated Zone FT Item's configuration.

### Shift management (added v8.30, enhanced v9.20)

Monitors and optionally enforces cardholder compliance with shift patterns, with configurable early/late arrival and late-departure grace periods:

| Configuration method           | Grace periods            | Alarms raised for                           |
| ------------------------------ | ------------------------ | ------------------------------------------- |
| PDF Shifts                     | 0, 1, 2, or 3 days       | Early arrival, Late departure               |
| 'Shifts' feature (v9.20+ only) | Between 0h00m and 23h59m | Early arrival, Late arrival, Late departure |

If a Competency is used, it is disabled or enabled in line with the shift. Instead of an early-arrival alarm, the cardholder is denied access until the Competency auto-enables at the start of their shift (start of the Start-shift grace period). Shift patterns are a start date, an optional end date, and a pattern (for example 7 days on / 7 off) defining access-granted vs access-disabled days.

**Example (PDF Shifts):** a 7-on/7-off pattern with a 1-day grace period can be configured to alarm if a cardholder arrives more than 1 day early, or has not left after 8 days (7 + grace) since shift start.

### Maximum entries (added v8.75)

Monitors and restricts how many times a cardholder may enter an area within a specified period. An alarm raises if exceeded.

## Use cases

* **Mining** (original): a mining-industry customer needing to manage staff fatigue under regulation, governing time-on-site per shift, across shifts, and minimum inter-shift breaks.
* **Prison**: alert a guard if visitors overstay a defined area.
* **Hospital**: alert staff if day-leave patients do not return on time.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.security.gallagher.com/knowledge-hub/products/cc-software/configure/command-centre-fatigue-management-vs-r.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.