How to Track Refrigerated Containers from Port to Port

A reefer container crosses the Pacific. Fourteen days later, it arrives with $2.3 million in spoiled pharmaceuticals. The carrier’s tracking system shows the container reached its destination on time. The temperature logs show a 37-hour excursion that started on day four. Nobody knew until the doors opened.

This is the visibility gap that costs the cold chain industry billions annually: knowing where a reefer is versus knowing what’s happening inside. Solving it requires more than a GPS tracker or a carrier API. It requires integrating three distinct data layers across connectivity dead zones that can last 72 hours or more.

Here’s how to build that capability.

Understanding the Three Data Layers

Effective reefer container monitoring depends on combining three categories of data that, individually, tell incomplete stories.

Location Data

The foundation. This includes AIS vessel tracking (where the ship is), GPS from tracking devices affixed to containers, and carrier milestone APIs reporting port events. Location data answers “where,” but a container sitting at the right coordinates can still contain ruined cargo.

Container Telemetry

The critical layer most operations lack in real-time. This includes temperature readings, setpoint values, power status, compressor cycles, and defrost events. This data comes from the reefer unit’s controller. This layer answers “is the refrigeration system doing its job,” but without location context, you can’t correlate anomalies to events (vessel fuel issues, port power disconnection, rough weather).

Environmental and Contextual Data

The early-warning layer. Environmental sensors capture humidity, door open/close events, vibration and shock, and for produce shipments, ethylene and CO2 levels. Contextual data like vessel schedules, port congestion, and weather patterns helps distinguish real problems from expected variations.

Why all three matter: Temperature telemetry without location can’t explain why an excursion happened. Location without telemetry can’t tell you if one happened. Neither without environmental context can predict one before it happens.

When a reefer’s temperature rises during a scheduled defrost cycle, that’s normal. When it rises while the door sensor shows an open event at a transshipment port, that’s a problem. The difference is integration.

Data Source Options and Trade-offs

No single source provides complete visibility. Here’s what’s available and what each actually delivers.

Carrier APIs

Major shipping lines offer tracking APIs with container milestone events, and increasingly, temperature data. The catch: data latency ranges from near-real-time to 24+ hours depending on the carrier. Coverage and data fields vary significantly across carriers, making multi-carrier normalization a substantial engineering effort. For baseline visibility and compliance documentation, carrier APIs are necessary but insufficient alone.

Third-Party IoT Devices

Retrofit sensors mounted inside or outside the container provide independent telemetry. Ownership models vary: some shippers purchase devices, others rent per-voyage. Battery life is the primary constraint. Devices must survive 30+ day voyages while transmitting via satellite, which typically means hourly or less frequent reporting intervals to preserve power.

Built-In Reefer Unit Data

Modern reefer units from major manufacturers include Controller Area Network (CAN) interfaces that expose rich operational data: compressor status, evaporator and supply air temperatures, defrost cycles, alarms. Accessing this data requires either physical gateways installed on containers or agreements with carriers who’ve deployed connected reefer fleets. The data is comprehensive but access varies dramatically by carrier and route.

AIS Vessel Tracking

AIS provides vessel position, heading, and speed. Correlating container to vessel to position requires maintaining accurate container-to-vessel manifests, a data management challenge when transshipments are involved. AIS fills location gaps between port milestones but provides nothing about container conditions.

Connectivity: Getting Data Off the Container

Mid-ocean, a container is a steel box 200 miles from the nearest cell tower. Getting data from that box is the fundamental technical challenge of maritime reefer monitoring.

Satellite

Iridium and similar LEO constellations provide global ocean coverage. The trade-off: higher cost per message, lower bandwidth, and power consumption that limits transmission frequency. Typical satellite-connected reefer devices report every 1-4 hours to balance visibility against battery life and cost. Expect $0.15-0.50 per message depending on payload size and contract terms.

Cellular

4G/LTE provides high-bandwidth, low-cost connectivity, but only within roughly 20 miles of coastline. For containers spending significant time in port or on coastal routes, cellular-only devices can work. For trans-oceanic voyages, cellular provides a 3-7 day blackout mid-journey.

Hybrid Approach

The most effective implementations combine both: cellular for high-frequency updates near shore, satellite for hourly updates mid-ocean. Devices switch automatically based on network availability. This approach typically adds 30-50% to hardware cost but eliminates the coverage-versus-cost trade-off.

Store-and-Forward

All maritime IoT devices must handle connectivity gaps gracefully. The device logs readings locally at high frequency (every few minutes), then transmits summaries or exception alerts when connectivity is available. This means you might not know about a temperature excursion until the satellite window, but you won’t lose the data entirely.

Decision framework: Use cellular-only for coastal routes under 5 days. Use satellite for trans-oceanic high-value cargo where the monitoring cost is small relative to cargo value. Use hybrid for pharmaceutical, biotech, or other zero-tolerance cargo where any visibility gap is unacceptable.

Implementation Steps

Step 1: Define Monitoring Requirements

Start with cargo, not technology. Different commodities have different tolerance windows: pharmaceuticals might require ±2°C with zero excursions, while frozen seafood allows ±5°C with brief deviations. Compliance standards like FDA, USDA, and EU GDP dictate documentation requirements.

Map your routes to identify connectivity gaps. A Shanghai-Rotterdam voyage via Suez has different satellite coverage needs than a Santos-Antwerp run. Define alert thresholds that account for normal operational patterns: a 2°C rise during a 30-minute defrost cycle shouldn’t trigger the same response as a 2°C rise over four hours.

Step 2: Select and Integrate Data Sources

Start with carrier API integration. This provides baseline visibility across your entire container population at minimal cost. Establish normalized data schemas upfront. Container IDs follow ISO 6346 standards, but timestamp formats, temperature units, and event codes vary by carrier.

Layer IoT telemetry for high-value or high-risk cargo. You don’t need independent sensors on every container; focus on shipments where cargo value, spoilage risk, or compliance requirements justify the per-voyage cost.

If your volume justifies it, negotiate access to CAN bus data from carriers with connected reefer fleets. This provides the richest operational data but requires deeper integration work.

Step 3: Build the Aggregation Layer

The core technical challenge: correlating container ID → device ID → vessel → location across data sources with different latencies, formats, and update frequencies.

Your aggregation layer must handle:

• Identity resolution: The same container might be referenced by ISO code, booking number, or bill of lading across different sources
• Temporal alignment: Carrier APIs might report port arrival 6 hours after your GPS device detected the geofence crossing
• Conflict resolution: When two sources disagree on location or status, which wins?

Use event-sourced architecture where possible. Store raw data from each source immutably, then derive current state. This preserves audit trails and allows reprocessing when you improve your correlation logic.

Step 4: Configure Alerting and Exception Management

Alert fatigue kills monitoring programs. A system that generates 200 daily alerts gets ignored; one that generates 3 high-confidence alerts gets action.

Build context into alerts:

• Temperature rising + defrost cycle active = suppress alert
• Temperature rising + door open event = escalate immediately
• Temperature rising + no explanatory event = alert with moderate priority

Configure geofence triggers for port arrival and departure to automate milestone tracking. Establish escalation workflows: who gets notified first, how long before escalation, what actions are available at each level.

Step 5: Establish Data Retention and Compliance Reporting

Cold chain compliance requires continuous, unbroken temperature records. Define retention periods based on regulatory requirements (often 1-3 years) and customer contracts.

Structure data for audit readiness: chain of custody documentation should link temperature records to specific container moves, with timestamps that align to port and vessel events. Pre-build compliance report templates for FDA, USDA, and customer-specific formats.

Common Pitfalls to Avoid

Single-source dependency. Carrier APIs go down. Satellite constellations have outages. Device batteries fail. Design for graceful degradation when any single source is unavailable.

Alert threshold tuning. Default temperature thresholds generate noise. Invest time in analyzing historical patterns to set thresholds that catch real problems without crying wolf during normal operations.

Defrost cycle false positives. Reefer units periodically warm evaporator coils to clear ice. This causes brief temperature spikes that look like excursions if your system doesn’t understand defrost cycles. Integrate defrost status or use pattern recognition to filter these.

Underestimating normalization. Twelve carriers means twelve different API schemas, timestamp formats, event codes, and update frequencies. Budget significant engineering time for data normalization. It’s often 40% of the integration effort.

Where This Is Heading

The baseline capability of knowing location and temperature across a voyage is table stakes. The next wave is predictive: using compressor performance trends, ambient conditions, and historical patterns to predict failures before they cause excursions.

Machine learning models trained on thousands of voyages can identify early warning patterns: a compressor drawing slightly more power than normal, defrost cycles running longer than expected, or supply air temperature diverging from setpoint in ways that precede failures by 24-48 hours.

Building the multi-layer monitoring architecture described here positions you to capture the training data for these models. Start with visibility. Graduate to prediction.

For deeper technical context on vessel position data, see our guide to [AIS vessel tracking]. For regulatory requirements driving these monitoring investments, explore our [cold chain compliance] overview.

Hubble Network’s satellite-connected sensors deliver temperature and location data from refrigerated containers mid-ocean, where cellular networks don’t reach. See how it works →