WCS Data Retention: How Long to Keep Equipment Logs and Alarm Records

Here's the bottom line: WCS data retention comes down to three sentences. One: keep raw second-level data for 30–90 days, minute-level aggregates for one year, and daily summaries plus critical events forever. Two: store it in three tiers — the local industrial PC holds only hot data, an edge server holds aggregates and the one-year window, and the cloud is for cold archive only. Three: alarm records and operation audit logs get pulled out separately and kept per regulatory and contract requirements — a different retention policy from equipment logs entirely. Below is why it's set up this way, and the step-by-step to land it before go-live.

Why WCS Data Retention Is Split This Way: Start With Who Comes Looking

Only three kinds of people ever query WCS data. First, incident investigators: something crashed, goods were damaged, a line stopped, and they need to reconstruct "what exactly happened." That needs raw second-level data — aggregates can't rebuild the scene. Second, OEE and efficiency analysts: equipment effectiveness, downtime distribution. They want aggregates; nobody computes monthly OEE from second-level points, that's self-harm. Third, auditors and compliance: they want "who acknowledged this alarm, and when" and "who changed which parameter." Operation records, every single one.

The retention policy is reverse-engineered from those three users. Figure out who queries, at what granularity, and how far back — the matrix practically draws itself. Conversely, anyone telling you "just keep everything, it'll be useful someday" has never run operations. Data nobody queries is data you never stored.

Here's the counterintuitive call up front: the thing most worth keeping forever isn't equipment logs — it's configuration change records and alarm acknowledgment records. Equipment logs answer "what happened." Configuration changes answer "why it happened." Nine out of ten incident reviews I've run ended at "who changed which parameter." I've seen this pitfall three times: all the data was there, but nobody could find who changed a photoelectric sensor's delay from 200ms to 800ms, and the review meeting turned into a blame session.

Now the math. Here's the formula — plug in your own warehouse's numbers:

Daily volume ≈ point count × 86,400 (seconds/day) × bytes per record

Worked example: 2,000 points, 1-second sampling, 50 bytes per record — about 8.6 GB per day, roughly 780 GB over 90 days. That's why raw data can't be kept forever: not because storage is unaffordable, but because nobody queries it. Keeping it is just digging a grave for your SSD. 780 GB of hot data on a local industrial PC means slow queries and painful backups — and one day it fills the disk, which is exactly pitfall number one below.

WCS Data Retention, Step by Step: Five Things Before Go-Live

Inventory your data types. WCS data falls into exactly five buckets — one row per bucket, no skipping: PLC point logs, alarm records, task trajectories, operation audit logs, configuration/program changes. While inventorying, note each bucket's source (which PLC, which service writes it). When something breaks later, you read the table first instead of flailing.
Draw the data retention matrix. Use this format; fill in the numbers for your own site:

Two notes: alarm-record raw retention doesn't get a fixed number of days — write "per regulation/contract," because industries and customer contracts differ, and a hardcoded number becomes a liability when contracts change. Operation audit and config changes are permanent but tiny in volume, so store them with confidence — this is the "most worth keeping forever" from the section above.

Set the storage tiers. The local industrial PC's SSD holds only 7–30 days of hot data, so queries still work during a network outage. The edge server holds aggregates and the one-year window. The cloud does cold archive only. One rule: don't put hot data in the cloud — egress and query fees will teach you a lesson. If unsure, run the volume formula first, compare against a one-time edge server investment, and decide on the math, not gut feel.

One more hidden cost of cold archive: retrieval. Cold archive is cheap, but getting data back takes hours to a day — an eternity during an urgent incident investigation. So "kept forever" doesn't mean "online anytime." When setting the data retention policy, confirm the retrieval SLA with auditors and customers first: anything that tolerates next-day retrieval goes to cold archive; anything that doesn't stays on the edge server. Settle this trade-off before go-live — migrating archived data after the fact is far more work than you'd think.

Automate cleanup and archival. Scheduled jobs plus disk watermark alerts: alert at 80% full, auto-archive the oldest data at 90%. Send the watermark alert somewhere a human actually reads — the on-call chat group, the duty phone — not a public mailbox nobody opens. Every archival run writes a log: how much archived, how much deleted. The books must balance.
Handover documentation. Three deliverables for the ops team, all mandatory: the retention matrix (signed by stakeholders — a signature means "this policy is agreed"); the cleanup/archival job list (schedule, owner, failure runbook); and one archive-restore drill record (proof the archived data can actually be read back — a drill never performed is an archive that exists only on paper).

WCS conveyor line with control cabinets

Common Failure Modes: I've Seen All Four

First: no retention policy at go-live at all. October 2024, a large e-commerce warehouse in eastern China: two weeks before the Singles' Day peak, the WCS industrial PC's local disk filled with logs and the system froze. Recovery: four hours of downtime, emergency export and archival, scheduled cleanup added, watermark alerts patched in. I've seen this pitfall three times, each more expensive than the last — first in a test environment, second in the off-season, third nearly during peak. The lesson in one sentence: the retention policy belongs on the go-live checklist, not on operations' "we'll figure it out later" list.

Second: aggregation logic frozen in code, raw data deleted. One site deleted second-level data after 90 days; six months later management wanted a different OEE formula, and the raw material was gone. All they could do was back-calculate from the old aggregates — wrong in every direction. Lesson: before deleting raw data, confirm the aggregation definitions are frozen. If unsure, extend raw retention to 180 days. Double the storage cost buys you regret insurance, and it's cheap insurance.

Third: alarm records mixed in with operation logs. A 3PL kept alarm records only 30 days; four months later a customer claimed cargo damage and asked for the alarm records and task trajectories from that day — unavailable, so they paid out on the customer's terms. Set alarm-record retention before signing customer contracts, and attach it to the contract. Fixing it afterward costs ten times planning it beforehand.

Fourth: cleanup jobs nobody watches. Watermark alerts went to the mailbox of someone who'd left three years earlier; the disk filled up before anyone noticed, and the archival job had been erroring for three months unnoticed. The handover list must name the alert recipient, name the successor when they leave, and get the successor's signature. It's old-fashioned. It works.

Go-live night checklist — add these three lines at the end: retention matrix signed off by stakeholders; cleanup job run manually once, logs verified for archival and deletion; one archive-restore drill, randomly pulling one three-month-old archive and reading it back. Once those three lines are done, you can say data is closed-loop. If they're not done, go do them now.

By Lin Xiao, WMS Implementation Consultant