Cold Chain Temperature Logs: AI Flags Breaches in Logger Exports

Export each data logger's readings as a CSV, strip anything that is not time, temperature and logger name, then give the AI your limits and time allowances and ask it to list every period outside them, with start, end, duration and peak. Recheck the worst events in a spreadsheet. The AI screens; you decide what happens to the stock.

A logger records thousands of readings and nobody reads them all. Most days they are boring, which is the point, and the day they are not is the day a compressor tripped at 14:05 and nobody noticed until a customer rang. A short, repeatable AI review turns the pile into a list of events, gaps and suspect sensors in a few minutes, with a corrective-action note drafted for the ones that matter.

Follow me on Instagram@sagnikteaches

What a logger export looks like, and how to tidy it

Most loggers produce a CSV (a plain text table) through their app or a web portal. The layout varies, but you will usually see a few lines of metadata at the top (device name, serial number, start time, interval), then a table of timestamp and temperature. Some also include humidity, a battery reading or an alarm flag. A raw export is rarely tidy enough to analyse directly. Common problems:

Connect on LinkedInSagnik Bhattacharya

• Header junk. Five lines of device details before the real header row.
• Units inside the cells. Values such as "4.8 °C" are text, not numbers, so a spreadsheet cannot compare them.
• Decimal commas. Some loggers write 4,8 for 4.8, which a spreadsheet may read as text.
• Text timestamps. Dates written as "05/11/2026 14:05" are ambiguous between day-first and month-first formats.
• Mixed units. One logger in Fahrenheit, the rest in Celsius.
• Extra columns such as route names, delivery sites or driver names that the analysis does not need and that you should not upload.

Keep the original file untouched in a folder, and work from a copy. A before and after, with made-up rows:

Subscribe on YouTube@sagnikteaches

BEFORE (raw export)
Device: VAN-2 | Serial: [serial] | Interval: 5 min
Start: 2026-11-05 00:00
---
Time,Temp,Driver,Site
05/11/2026 14:05,"5,4 °C",[driver],[customer site]

AFTER (clean copy for analysis)
timestamp,logger,temp_c
2026-11-05 14:05,VAN-2,5.4

Notice what went. The driver and the customer site have no part in finding a breach, so they are not uploaded. If you later need to know which delivery was affected, you join the timestamp to your own delivery records, on your own machine. This keeps customer and staff details out of a third-party tool. If tidying many files, cleaning messy data with AI shows how to do it in bulk, and the same advice applies: keep the original, change the copy.

Write the rules down before the AI sees the file

An AI tool cannot know what counts as a breach for your products. You tell it, in numbers, and the numbers come from your own food safety plan and your regulator, not from this tutorial or from the tool. The illustrative rules for the example distributor below are:

1. Chilled limit: 5.0 °C maximum, with readings between 0.0 and 5.0 acceptable. (Your limit for some products may be different.)
2. Short excursion: readings above 5.0 for less than 30 minutes in a row, such as a door opened during loading. Log and watch, no action.
3. Minor breach: above 5.0 for 30 minutes or more in a row. Needs a note and a check of the stock.
4. Major breach: any single reading above 8.0, or above 5.0 for 120 minutes or more. Needs the stock quarantined until the owner decides.
5. Frozen limit: -18.0 °C or colder for frozen goods, with the same time logic.
6. Data problems: a gap in readings longer than 15 minutes, or the same value for more than 4 hours, is a data quality flag, not a pass.

Writing the rules in this form forces decisions you may have never made explicit, such as how long "too long" is. It also makes the AI's job mechanical, which is what you want: it applies your rule, it does not invent one. If your plan gives different limits for different products or rooms, write one rule set per logger and label them.

The prompt that returns an events table

The attached CSV has columns timestamp, logger, temp_c. Readings are every
5 minutes. Apply these rules to each logger separately:

- Limit: temp_c must be between 0.0 and 5.0 inclusive.
- A "run" is consecutive readings above 5.0. Its duration is from the first
  reading above 5.0 to the first reading back at or below 5.0.
- Short excursion: run under 30 minutes. Minor breach: 30 to 119 minutes.
  Major breach: any reading above 8.0 OR a run of 120 minutes or more.
- Data problems: gaps between readings longer than 15 minutes; a value that
  repeats for more than 4 hours.

Output a table: logger, run start, run end, duration in minutes, peak temp_c and
its time, number of readings in the run, classification. Then list the data
problems separately. Show the number of readings you analysed per logger.
Do not suggest causes, and do not say whether stock is safe.

The line about the number of readings per logger is a quick integrity test. At five-minute intervals one logger produces 288 readings a day, so a day with 240 means something went missing. The last instruction matters as well: you want findings and not verdicts. Cause and safety are for a person with the product knowledge and the legal responsibility.

The main example: one van, one bad afternoon

Take an illustrative small food distributor of chilled dairy and deli items, with a three-van fleet and a cold room. Logger VAN-2 gives 279 readings for 5 November, nine short of the 288 a full day should hold. The AI's events table (illustrative) reads:

It adds two data problems: a gap in readings from 09:05 to 09:55 (50 minutes, nine readings missing) and no flatlines. Check the arithmetic as an owner would. The 14:05 run covers readings from 14:05 to 15:15 at five-minute spacing, which is (15:15 - 14:05) / 5 + 1 = 70 / 5 + 1 = 15 readings. The first reading back in limit is at 15:20, so the duration is 75 minutes. It is under the 120-minute test but the 8.3 peak makes it a major breach by the other rule. The 02:15 run has five readings and ends at 02:40, giving 25 minutes, which is below the 30-minute threshold. If the AI had called it a minor breach, you would know it had misapplied the rule.

The gap is not harmless. Fifty minutes without readings, between 09:05 and 09:55, means the van might have been out of limits and nobody can say. Treat a gap as unverified until someone explains it, perhaps a flat battery, the logger being moved, or an upload fault.

Check the worst event with spreadsheet formulas

Do not accept any breach on the AI's say-so alone. Open the clean CSV in a spreadsheet, put timestamps in column A and temperatures in column C, leave row 1 as headers and row 2 as the first reading. Two helper columns rebuild the run logic:

• In D2, =IF(C2>5,1,0) marks each reading above the limit. Copy it down.
• In E2, =IF(D2=1,E1+1,0), with E1 set to 0 or left as a number, counts readings in a row. Copy it down.
• To find the longest run, =MAX(E:E)*5 gives minutes when readings are five minutes apart. For the example, MAX returns 15 readings and the formula returns 75 minutes, matching the table. Whatever way you count, use the same one your food safety plan uses.
• To find the peak: =MAX(C:C), returning 8.3.

Filter column D for 1 and look at the rows: you should see 14:05 to 15:15 as a single block, and the five early-morning rows. If your sheet disagrees with the AI, the sheet wins until you find out why. The usual culprits are a timestamp column that sorted as text, a decimal comma that turned 5,4 into text (MAX skips text, and a greater-than test on a text cell gives a misleading answer), or an interval that is not really five minutes.

When the data lies: sensors, placement and gaps

Readings can be wrong without any breach. A sensor that fails often flatlines on one value, or reads a steady 3.1 for six hours while the room warms up. A probe taped to a wall near the evaporator reads colder than the product. A logger left on the dashboard reads cab temperature. Ask the AI for these checks as a second pass:

1. "List any run of identical readings longer than four hours and the time it began." A real cold room varies by a few tenths of a degree as the compressor cycles. A perfectly flat line is suspect.
2. "Compare the average and the minimum for each logger. List any that sit below -1.0 or above 6.0 for the whole day." A reading that never rises near the product temperature may be measuring air next to the coil.
3. "Compare VAN-1, VAN-2 and VAN-3 during the 14:05 to 15:20 window and tell me whether the others also rose." If all three vans and the cold room rose at once, suspect the logger clock, power or a shared event. If only one rose, suspect that van.

The third check is the most useful. It is the kind of pattern comparison that is slow by eye across 288 rows and quick for a tool. It does not give you the cause, but it narrows where to look. Link it to other data you hold: auditing yard time and tolls from telematics shows how vehicle records can help here: if your telematics logs stops or door events, they may show whether a van was parked with its doors open at 14:05.

Draft the corrective-action note, leave the decisions to you

Once a breach is confirmed, a record has to be written. This is where AI saves the most time and does the least harm, as long as it drafts only what you tell it and leaves decisions empty. A prompt that works:

Draft a corrective-action record for the confirmed breach below. Use these
headings: Event, Detection, Product affected, Immediate action, Investigation,
Preventive action, Sign-off. Fill in only the facts I give you. For anything
that needs a decision or a fact I have not given, write [OWNER TO COMPLETE].
Do not state that the product is safe or unsafe.

Facts: logger VAN-2; run 14:05 to 15:20 on 5 November; 75 minutes above 5.0;
peak 8.3 at 14:40; loaded at 13:30 with 40 cases of chilled dairy and deli
(delivery list attached by reference); door and refrigeration unit status
unknown; no alarm received.

A realistic output (illustrative) would give an Event line with the figures, a Detection line saying the breach was found in the next-morning review of the logger export, a Product affected line listing "40 cases, see delivery list", and then blanks for the immediate action, the investigation and the preventive action. That is correct behaviour. If the draft says "stock was inspected and found safe", it has invented a fact, and the instruction should be tightened.

A quick sum puts the potential loss in context: 40 cases at an average cost of $22 is $880 of stock under question. Compare that with the cost of a replacement logger or a maintenance call for the refrigeration unit and the decision about preventive action becomes concrete. If it recurs across several vans, the pattern points at a fix worth paying for. For the audit trail around all this, preparing for a food-safety audit with AI checklists covers how to present these records to a third party.

A mistake that passed because nobody checked the clock

Here is an illustrative failure that is easy to fall into. A distributor's morning breach list is off by an hour for months after the clocks change, because the loggers keep standard time all year while the delivery system follows daylight saving. The AI correctly flags a 90-minute breach, but it is matched to the wrong delivery, and the team quarantines the wrong pallets. The fix is to record, for every logger, which time standard it uses and whether it adjusts, and to store that in the file name or a metadata line. When you join logger data to delivery records, ask the AI to state any assumption about time zones and compare one known event, such as a door-open scan, against the log to confirm the offset.

A weekly summary the owner will actually read

Daily events are for the person doing the review. The owner needs a weekly page. Keep each day's event table, then ask for a roll-up across the week with a layout that fits one screen:

All figures here are illustrative. A week at five-minute intervals gives 7 x 288 = 2,016 readings per logger. VAN-2 shows 1,980, which is 36 readings short, or three hours of missing data, and that is why the data-gap column exists. Time in range is readings within limits divided by readings received. For VAN-2, if 64 of its 1,980 readings were above 5.0, the figure is (1,980 - 64) / 1,980 = 96.8%. Notice that the percentage alone hides the distinction that matters: 99% sounds excellent, but 1% of a week is 100 minutes, which could be one bad run that spoiled a delivery. Keep the counts of minor and major breaches next to it, and treat a rising count of short excursions on one logger as an early warning.

Before and after: the message to the person responsible

When a breach is confirmed, a short message goes to whoever must act, usually the owner or warehouse lead. An AI draft can be too long and too sure of itself. Here is the usable version beside the one to avoid (both illustrative).

AVOID
"Temperature breach on VAN-2 was caused by the refrigeration unit failing at
14:05. The dairy is unsafe and should be discarded."

USE
"VAN-2 logger: above 5.0 C from 14:05 to 15:20 (75 min), peak 8.3 C at 14:40.
Loaded 13:30 with 40 cases chilled dairy and deli. Cause unknown; the other
vans and the cold room stayed in range. 50-minute data gap 09:05-09:55 earlier
the same day. Needs: your decision on the stock, and a check of the unit and
the door seal. Draft corrective-action record attached for your completion."

The second version states what the record shows, what is unknown and what is needed. It makes no claim about cause or safety. If your prompt says "report only what the data shows; list unknowns separately", most tools will give you something close to it.

Three smaller businesses, three variations

• A frozen seafood wholesaler runs a -18.0 limit and cares more about warming spikes during defrost cycles. The prompt adds a rule that a scheduled defrost window, such as 03:00 to 03:30, is excluded from breach counts only when the peak stays below a limit written in the plan.
• A caterer with one cool room and a delivery van logs both on one tool and reviews weekly, so the prompt compares the room's readings with the van's on event days, to see whether prepared food left the room already warm.
• A café group with fridges in three sites uploads one file per site, adds the site code as the logger name, and asks for the worst fridge of the week and any that stayed above the limit overnight, which suggests a door left ajar after close.

In each case the method is unchanged, with new numbers: write the limits down, clean the file, ask for findings only, check the worst case yourself, and keep the decision with a named person.

A daily routine that takes ten minutes

1. Download yesterday's exports for every logger into a dated folder. Do not rename originals.
2. Clean copies by removing everything except timestamp, logger and temperature. A saved spreadsheet macro or a short, tested prompt can do this.
3. Run the events prompt with your rules at the top.
4. Verify any minor or major event with the helper columns and look at the gap list.
5. Decide and record: the owner or food safety lead signs a one-line decision for each event, even "no action, door opened for loading".
6. Draft corrective actions for confirmed breaches and file them with the original export.

A weekly extension is to ask for repeat patterns: "Which logger had the most short excursions this week, and at what times of day?" Several excursions at 06:30 each day usually mean a loading routine, which is fixable with a curtain, a different door procedure or loading in smaller batches. If you also review your counts, finding why your count and system disagree helps tie discarded product back to the breach that caused it.

What stays with the owner

An AI tool should never be the author of your temperature limits, the judge of whether product is fit to sell, or the signatory of a record. It does not know your products, your supplier's shelf-life terms, your plan, or what your regulator requires, and it can be wrong while sounding certain. Rules differ by market and product, so keep the limits in your own food safety documents and have them reviewed by the person who is qualified to write them. A sensible working split: the AI finds and summarises, a trained person reviews and decides, and the record shows both.

The same approach suits other temperature-controlled work. A caterer with a cool room, a pharmacy-grade fridge for a small clinic, or a bakery with a blast chiller each has a different limit set but the same export, rules, checks and sign-off. If you want a hand building this around the loggers you already own, book an AI implementation consultation and we will work out the rules and the review together.

Questions about AI and temperature logs

Can AI decide whether stock is safe to sell?

No. AI can find and summarise readings outside your limits, but the decision to sell, discard or quarantine stock rests with the owner or the food safety lead, using your own food safety plan and the rules your regulator sets. Treat the AI output as a screening list.

What limits should I give the AI?

Use the limits and time allowances written in your own food safety plan, since they depend on the product and your regulator. The numbers in this tutorial, such as 5 degrees for chilled goods, are illustrations only, so replace them with yours before you run anything.

How big a file can I upload?

Limits change between plans and tools, so check the current upload help page. A month of five-minute readings from several loggers can run to tens of thousands of rows, which is better analysed with a tool that runs code on the file than pasted into a chat.

Do I still need the logger's own alarm?

Yes. A weekly or daily review finds problems after the event. Real-time alarms from the logger or monitoring system tell someone while the stock can still be saved. The AI review is the second layer, catching patterns, gaps and repeat offenders.

Is a log reviewed by AI acceptable to an auditor?

Auditors care that records are accurate, reviewed and acted on, and that a named person signed them off. Keep the raw export unchanged, record who reviewed it and what they decided, and keep AI output as a working note, not the official record.

Further reads

• AI for Food Distributors: Taking Restaurant Orders on WhatsApp — Take restaurant orders on WhatsApp for the same distributor.
• Allergen Matrix Template: Build From Recipes With AI, Then Verify — Another record a food business must keep accurate.
• AI for Delivery Managers: A Daily Exceptions Report From Route Exports — The same exceptions method for daily route data.
• AI for Industrial Manufacturing: Read Downtime Logs to Find Repeat Stops — Read equipment logs for repeat stops, as here for repeat breaches.
• Best AI for Supply Chain: Delay Alerts and Reorders Without an ERP — Link delays to the loads most at risk.
• Can ChatGPT Write a HACCP Plan for a Restaurant? What to Verify — What ChatGPT drafts well in a HACCP plan, what it guesses, and the checks your food safety authority still makes: limits, logs, thermometers and training.
• Commercial Refrigeration Service Software: What AI Adds — What AI adds to service software for a commercial refrigeration firm, where it helps with call-outs and fault notes, and what stays manual.
• Goods Received Note Template: Match Deliveries to Orders With AI — What a goods received note should record, a template to copy, and how AI turns a delivery photo into a matched, flagged table.
• Lot Numbering System for a Food Producer: Design Batch Codes — A lot code built from date, line and shift, tied to ingredient lots and tested with a mock recall before you need it.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: general cold-chain monitoring practice and data-logger export formats. All limits, readings, values and times in the example are illustrative; use the limits in your own food safety plan and your regulator's rules.