> For the complete documentation index, see [llms.txt](https://docs.datacake.de/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.datacake.de/portal/reports/report-builder/cold-chain-monitoring-template-and-widgets.md).

# Cold Chain Monitoring Template & Widgets

Configure, interpret, review, and sign off cold chain reports

## Overview

The Cold Chain Monitoring report template provides a ready-made structure for reviewing temperature performance across a fleet of monitored devices. It combines fleet-level KPIs and a time-series chart with three cold-chain-specific widgets for compliance review, excursion assessment, and approval.

| **Component**               | **Purpose**                                                                             |
| --------------------------- | --------------------------------------------------------------------------------------- |
| Fleet KPIs                  | Summarize the maximum, minimum, and average temperature across all included devices.    |
| Cold Chain Monitoring Table | Provide a device-by-device, grouped or both compliance overview                         |
| Fleet time-series chart     | Plot fleet minimum and maximum temperature against configurable lower and upper limits. |
| Cold Chain Excursion List   | List individual temperature and/or humidity excursions for assessment and sign-off.     |
| Sign-off                    | Provide a final approval area for a responsible reviewer.                               |

## Cold Chain Widgets

### Cold Chain Monitoring Table

The Cold Chain Monitoring Table is the fleet overview. It evaluates every selected device and/or each hierarchy group, against configured temperature and/or humidity targets and presents the result using green, yellow, and red status colours.

#### Row and device identification options

* **Row layout.** Display one row per device, one row per group, or groups with their devices underneath. Groups are taken from the device hierarchy configured in the report "Settings".
* **Device identification.** Show the device name alone, or add the serial number and location description.
* **Additional columns.** Enable or disable the available metric and device-health columns to match the intended audience. You can decide to display the columns:&#x20;
  * In Range: Share of covered time spent inside the target range. Warning below 99% and critical below 95% by default; both thresholds are configurable.
  * Longest Excursion: The single longest uninterrupted period outside the target range, including its time window. Critical-from duration controls when an excursion makes the row non-compliant by itself. A shorter excursion is still displayed but does not affect the grade. A value of 0 leaves no tolerance.
  * Min/Max: Lowest and highest reading anywhere in the row. Values are coloured when they leave the target range. Uses the configured target minimum and maximum.
  * Coverage: How completely the metric was recorded during the report period. Warning below 98% and critical below 90% by default; both thresholds are configurable.
  * Battery: You can display device battery. Make sure the Semantic "Battery" is selected in the field.

#### Core measurement settings

| **Setting**     | **Meaning**                                                                                                                                |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| Sample validity | Define how long one sample remains valid. After this period, time is counted as missing rather than as a continuation of the last reading. |
| Target range    | Define the minimum and maximum acceptable values. Values outside this range count toward excursions.                                       |
| Humidity        | Optionally add humidity with its own minimum and maximum target values when devices report humidity.                                       |

{% hint style="info" %}
Why sample validity matters: Sample validity affects both data coverage and excursion calculation. If reporting stops during an excursion and the validity period expires, the gap is treated as missing data. One apparent long excursion is therefore reported as two shorter excursions.
{% endhint %}

A legend below the table summarises the target range, time-in-range thresholds, longest-excursion critical duration, coverage thresholds, sample validity, and status colors: green for OK, yellow for warning, and red for critical.

{% hint style="warning" %}

#### Look-around window (Time-range & Resolution of the report)

The report period alone may cut through an excursion that began earlier or ends later. The look-around window lets the calculation inspect data before and after the report window so the longest-excursion result can better reflect the surrounding event.

Boundary wording. Expressions such as “at least \<duration>”, “… or earlier”, or “… or later” indicate that the excursion may continue beyond the report window plus the configured look-around window.

Interpretation. Boundary wording signals uncertainty: the true excursion may be longer than the duration shown.
{% endhint %}

### Cold Chain Excursion List

The Cold Chain Excursion List presents each qualifying excursion as a separate record. It is intended for detailed review, investigation, disposition, and sign-off by the responsible person.

#### Excursion calculation settings

| **Setting**      | Meaning                                                                                                           |
| ---------------- | ----------------------------------------------------------------------------------------------------------------- |
| Semantic         | Select temperature or humidity.                                                                                   |
| Sample validity  | How long a sample remains valid. Missing data after the validity period splits an otherwise continuous excursion. |
| Target range     | Minimum and maximum acceptable values; 2 °C to 8 °C are the default temperature limits in the template.           |
| Minimum duration | Only excursions lasting at least this long are listed; the template default is 30 minutes.                        |

#### Exposure

Enable Show exposure to add an exposure column. Exposure combines how far readings exceeded the configured limit with how long they remained outside the range, expressed in degrees Celsius per hour (°C·h).

{% hint style="warning" %}
Interpret exposure together with the peak: A long, shallow excursion can produce the same exposure as a brief, deep excursion. Use exposure to compare total thermal burden, but always read it alongside the peak reading and excursion duration.
{% endhint %}

#### Device information and review fields

Device identification can include the serial number and location description. The widget can also provide fields for documenting the outcome of the review:

* Assessment outcome
* Disposition
* Record reference
* Signer name
* Sign date
* Signature

#### Excursion IDs: important behaviour

{% hint style="warning" %}
Excursion IDs are generated for each report run. Datacake does not currently store and track excursions as persistent native records. Excursion IDs are calculated when the report is generated (“on read”). Do not use the ID as a permanent cross-report identifier.
{% endhint %}

* The same real-world excursion receives a different ID in another report run, even when the report configuration and time frame are unchanged.
* An excursion repeated in reports with overlapping periods receives a new ID in each run.
* The ID remains the same only for the same report run, such as a back-office regeneration of that run with the same configuration.
* If new historical data is backfilled, the enumeration can shift, which may change assigned IDs even during regeneration.
* For durable audit references, store the excursion’s device, start and end timestamps, measured limits, and the generated report/run reference together—not the excursion ID alone.

### Sign-off widget

The Sign-off widget provides a simple approval block intended for a printed PDF. A responsible person can confirm that the report, device status, and recorded excursions have been reviewed.

* Title. The default “Approved by” label can be changed.
* Name. Identifies the responsible reviewer.
* Date and time. Records when the report was approved.
* Signature. Provides space for the reviewer’s handwritten signature.

## Recommended review workflow

1. Confirm the report period, included devices, device hierarchy, and output format.
2. Verify the target ranges and sample-validity settings for every monitored semantic.
3. Review fleet KPIs and the chart for broad temperature trends.
4. Use the Cold Chain Monitoring Table to identify warning, critical, or unreliable rows.
5. Open the Excursion List and assess duration, peak, exposure, and surrounding data for each event.
6. Document the assessment outcome, disposition, record reference, and reviewer details.
7. Complete the final Sign-off block after all exceptions have been reviewed.

{% hint style="warning" %}
Before distributing a report check whether any excursion is marked “at least,” “or earlier,” or “or later.” These phrases mean the event may extend beyond the available report period and look-around data. Increase the look-around window or review a wider period when an exact boundary is required.
{% endhint %}


---

# 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://docs.datacake.de/portal/reports/report-builder/cold-chain-monitoring-template-and-widgets.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.
