Package help

How Package Tracking Actually Works

Learn how package tracking creates scans, events, statuses, estimates, handoffs, and late updates—and what a public tracking history can and cannot prove.

Public package tracking is usually a published history of selected events, not a continuous live map. A record can begin when a sender creates electronic shipment data, before the carrier records physical possession. Later updates can come from manual barcode scans, automated sortation, RFID sensors, carrier systems, customs milestones, postal data exchanges, delivery partners, and final-delivery devices. The public page may show a detailed event, a simplified status, and an estimated delivery date at the same time. Those elements answer different questions. A tracking event confirms what the responsible system recorded; it does not automatically prove the parcel’s exact current location, uninterrupted movement, normal timing, personal receipt, or a guaranteed delivery outcome.

First identify what you are looking at

A tracking page can display several different kinds of information together.

Tracking element What it is What it mainly answers
Event A recorded occurrence What did a system record?
Parent status A broad summary category What general stage is displayed?
Estimate A prediction When might delivery occur?
Action request A task or decision Who must do what next?
Proof attribute Evidence attached to an outcome What detail supports the recorded result?

These elements are not interchangeable.

Before interpreting a tracking page, determine which one you are reading.

The seven-layer tracking pipeline

A public tracking update can pass through several layers:

1. identifier
→ 2. shipment data
→ 3. physical or electronic observation
→ 4. carrier operational system
→ 5. data transmission
→ 6. public display
→ 7. user interpretation

A mistake at the interpretation layer can turn a limited record into an unsupported conclusion.

1. Identifier

A tracking number, waybill, postal identifier, delivery-notice number, or partner reference allows a system to retrieve a shipment record.

The identifier can exist before:

  • pickup;
  • acceptance;
  • movement;
  • customs processing;
  • local-carrier handoff.

A valid identifier does not by itself prove that the carrier has the parcel.

2. Shipment data

The sender, merchant, or shipping system can create:

  • origin and destination data;
  • service level;
  • billing information;
  • barcode;
  • parcel attributes;
  • customs data;
  • planned carrier or partner information.

This can create a public record even when the physical parcel remains with the sender.

3. Physical or electronic observation

A later event may be created by:

  • counter acceptance;
  • pickup;
  • manual barcode scan;
  • automated barcode reader;
  • RFID sensor;
  • facility processing;
  • container or dispatch relationship;
  • customs process;
  • delivery device;
  • partner-carrier message.

Not every observation becomes a public item-level event.

4. Carrier operational system

The carrier associates the observation with:

  • shipment;
  • location;
  • stage;
  • reason;
  • exception;
  • action eligibility;
  • estimated date.

5. Data transmission

The event may be transmitted to:

  • carrier website;
  • merchant;
  • marketplace;
  • destination carrier;
  • postal operator;
  • broker;
  • carrier API;
  • webhook subscriber;
  • multi-carrier tracking platform.

6. Public display

The user may see:

  • exact carrier phrase;
  • translated phrase;
  • parent status;
  • progress bar;
  • location;
  • estimated date;
  • action button;
  • map;
  • photo;
  • signature.

7. User interpretation

The display still requires careful reading.

Unsafe shortcuts include:

  • label exists, therefore carrier has the package;
  • no scan, therefore no movement;
  • In Transit, therefore the parcel is continuously moving;
  • city shown, therefore it is still in that city;
  • estimated today, therefore Out for Delivery;
  • partner named, therefore physical handoff occurred;
  • Delivered, therefore intended recipient personally received it.

A tracking record can exist before the carrier has the parcel

This is one of the most important tracking boundaries.

A sender can:

  • create a label;
  • buy postage;
  • create a waybill;
  • transmit shipment information;
  • assign a tracking number.

UPS distinguishes Label Created from later possession. DHL Express describes Shipment Information Received as a shipment record and waybill created in its system. DHL eCommerce also explains that the merchant can provide a tracking ID before the first carrier event appears.

Therefore:

Stronger possession evidence usually includes wording such as:

  • Accepted;
  • Picked Up;
  • We Have Your Package;
  • In Possession;
  • Received by Carrier;
  • item-level carrier facility event.

The dedicated carrier-received guide should control the exact possession decision for a shipment.

What creates a tracking event?

Sender-created data event

Examples:

  • Label Created;
  • Shipment Information Received;
  • Electronic Notification;
  • Customs Data Submitted.

This confirms that a record or data exists.

It does not necessarily confirm physical receipt.

Acceptance or pickup event

Examples:

  • Accepted;
  • Picked Up;
  • In Possession;
  • We Have Your Package.

This supports the conclusion that the named carrier recorded receipt.

Facility event

Examples:

  • Arrived at Facility;
  • Processed at Facility;
  • Departed Facility;
  • Sorted.

This confirms processing at the named network point at the recorded time.

It does not automatically prove:

  • the parcel is still there;
  • the next destination;
  • normal timing;
  • uninterrupted movement.

Transport event

Examples:

  • Departed Hub;
  • Transfer Through;
  • Gateway Transit;
  • Line-Haul Departure;
  • Dispatch milestone.

Some transport data remains internal or belongs to a container, receptacle, dispatch, or consignment rather than a new public item scan.

Customs event

The public status may be produced from data involving:

  • customs authority;
  • another government regulator;
  • carrier;
  • postal operator;
  • broker;
  • sender or importer.

The carrier can display the event even when a government authority controls release.

Partner event

Examples can represent different evidence:

  • partner assigned;
  • information transferred;
  • parcel tendered;
  • partner accepted item;
  • local carrier facility event.

Do not treat those as equivalent.

Delivery-route event

Examples:

  • Out for Delivery;
  • With Courier;
  • dispatched to driver;
  • loaded for delivery.

The operational meaning is carrier-specific.

Attempt event

Examples:

  • Delivery Attempted;
  • Notice Left;
  • Recipient Unavailable;
  • Access Issue;
  • Address Issue.

The detailed reason controls the next step.

Completion event

Examples:

  • Delivered;
  • Collected;
  • Delivered to Agent;
  • Safe Drop;
  • Locker Delivery;
  • Returned to Sender.

The exact outcome is more useful than a generic completed status.

Are all updates manual barcode scans?

No.

Tracking is event-based, but events can be created by different technologies and systems.

Manual barcode scan

A worker may scan the item at:

  • acceptance;
  • pickup;
  • facility;
  • route loading;
  • delivery.

Automated barcode reading

Sortation equipment can read barcodes while parcels move through a facility.

Not every automated read becomes a public event.

RFID sensing

UPS currently describes a U.S. network that combines conventional scans with RFID-enabled package sensing. Its tracking support states that an RFID-enabled label can be recorded when it passes a sensor without a manual scan.

This is a UPS-specific current capability.

It does not prove that:

  • every carrier uses RFID;
  • every parcel worldwide has RFID coverage;
  • every sensor event appears publicly;
  • every parcel has continuous location visibility.

Container and handling-unit visibility

Postal and carrier networks can track larger units such as:

  • tray;
  • sack;
  • pallet;
  • receptacle;
  • dispatch;
  • consignment.

USPS visibility systems cover individual items and larger handling units. UPU postal messaging can link an item identifier to a receptacle and exchange dispatch or transport information.

A parcel can therefore be associated with a known batch movement without receiving the same kind of new public item scan at every step.

That does not prove that every item remained in the expected container or completed the next item-level handoff.

Is package tracking live GPS?

Usually, no.

Public parcel tracking is generally a sequence of recorded events rather than a continuous GPS feed attached to every parcel.

What the location field usually means

A location normally belongs to the recorded event.

It can identify:

  • facility;
  • city;
  • gateway;
  • customs point;
  • delivery location;
  • route event.

It does not automatically show the parcel’s exact location at the moment the page is opened.

Carriers can offer additional location features

UPS currently offers a conditional Follow My Delivery map for eligible authenticated shipments near the delivery window. FedEx describes advanced visibility features that can include delivery predictions, proof images, and GPS coordinates associated with a delivered package.

Those features do not mean every parcel publishes continuous GPS throughout its journey.

Delivery coordinates are not journey-wide GPS

Coordinates associated with a delivered event can support the location of that delivery record.

They do not automatically prove:

  • continuous parcel tracking;
  • personal receipt;
  • correct-address delivery;
  • that every service exposes coordinates.

The safe rule is:

Treat the standard tracking history as selected recorded events unless the responsible carrier explicitly provides a separate live-location feature for that shipment.

Event versus status

An event is a specific recorded occurrence.

A status is an interpreted summary of the shipment’s current state.

Event structure

A detailed event can include:

date and time
+ location
+ carrier-specific wording
+ reason
+ requested action

One status can summarize many events

For example, In Transit can cover:

  • facility arrival;
  • facility departure;
  • line-haul movement;
  • gateway processing;
  • repeated network milestones.

One event can update several display elements

A new event can change:

  • parent status;
  • progress bar;
  • latest location;
  • estimated date;
  • action eligibility;
  • notification.

Read the detail before the progress bar

Use this order:

  1. exact raw event;
  2. responsible carrier;
  3. event timestamp;
  4. event location;
  5. detailed reason;
  6. requested action;
  7. parent status;
  8. estimated date.

A broad status is useful for orientation. It is usually weaker for diagnosis.

Raw carrier event versus normalized status

Carriers use different:

  • event codes;
  • languages;
  • phrases;
  • taxonomies;
  • levels of detail.

Marketplaces and multi-carrier platforms often map those different events into shared parent categories such as:

  • Info Received;
  • In Transit;
  • Exception;
  • Out for Delivery;
  • Delivered.

This process is often called normalization.

What normalization improves

  • consistent interface;
  • simpler progress display;
  • cross-carrier notifications;
  • easier comparison;
  • shared status categories.

What normalization can remove

  • exact possession evidence;
  • customs reason;
  • partner identity;
  • delivery-location detail;
  • action required;
  • difference between assignment and acceptance;
  • carrier-specific operational meaning.

A normalized status is not automatically wrong.

It is less specific.

Practical evidence hierarchy

For operational interpretation, prefer:

official carrier responsible for the current segment
→ exact raw event
→ official partner event
→ merchant or marketplace detail
→ broad normalized status

Example:

marketplace: In Transit
carrier detail: Clearance Delay — Importer Information Required

The detailed carrier event controls the action.

When did the tracking event actually happen?

The visible timestamp is not always one universal moment.

A tracking update can involve:

event occurred
→ event recorded
→ event transmitted
→ event processed
→ event displayed

Event time

The system records that the operational event occurred at a particular time.

Local operational time

International postal events can use local date and time associated with the event location.

A multi-country history can therefore contain times from different time zones.

Transmission time

The source system sends the event to another system.

Processing time

The receiving carrier, merchant, marketplace, or platform:

  • ingests;
  • validates;
  • translates;
  • deduplicates;
  • maps;
  • republishes.

Display time

The user finally sees the event.

Correction or republication time

An event can later be:

  • corrected;
  • supplemented;
  • republished;
  • reordered;
  • deduplicated.

The key boundary is:

unless the system explicitly indicates that both times are the same.

Can tracking updates appear late or out of order?

Yes.

Possible system-level reasons include:

  • delayed partner transmission;
  • batch processing;
  • time-zone conversion;
  • marketplace polling;
  • API or webhook delay;
  • later correction;
  • republication;
  • one platform receiving an event before another.

These are possible explanations, not a diagnosis of one shipment.

A documented 2026 example

In March 2026, FedEx reported delayed Advanced Integrated Visibility webhook event delivery and stated that missed events would be republished. FedEx separately documented an April 2026 delivery-data issue in which some delivery events were delayed or duplicated when corrected data was reprocessed.

Those incidents demonstrate that:

  • physical event time;
  • event creation time;
  • push time;
  • display time;

can differ in a live carrier system.

They do not prove that a specific consumer tracking delay was caused by an API incident.

Can a package move without a new public update?

Yes, it can.

FedEx states that packages are scanned at selected points between pickup and delivery and can travel for an extended period before the next scan. UPS likewise explains that long-distance movement can occur before the next destination-hub scan.

Possible contexts include:

  • trailer movement;
  • aircraft transport;
  • long-distance line haul;
  • sealed container;
  • dispatch or receptacle movement;
  • milestone-only service;
  • partner data not yet published.

The safe statement is:

The equally important limitation is:

The same silence can also occur during:

  • facility processing;
  • customs review;
  • handoff delay;
  • capacity disruption;
  • misroute;
  • missed scan;
  • data problem;
  • physical transport delay.

Silence alone cannot identify the cause.

Does every parcel receive a scan at every facility?

No universal evidence supports that.

A parcel can:

  • pass through an automated process;
  • remain associated with a container;
  • travel between public milestones;
  • receive an internal event that is not exposed;
  • miss an expected item-level scan;
  • use a milestone-only service.

This does not mean carriers have no internal visibility.

It means the public item history should not be treated as a complete log of every operational movement.

Why do two tracking pages disagree?

Different pages can use different:

  • data sources;
  • identifiers;
  • update schedules;
  • carrier divisions;
  • event taxonomies;
  • normalization rules.

Original carrier versus destination carrier

The original provider may show the international segment.

The destination carrier may show:

  • pre-advice;
  • acceptance;
  • local facility;
  • delivery.

Carrier versus marketplace

The carrier can publish a detailed event while the marketplace shows a broader category.

The marketplace can also receive or display a partner event at a different time.

Original number versus local number

The two records can expose different stages of the same journey.

Carrier auto-detection

A tracking platform can initially query the wrong carrier when number formats overlap.

Practical resolution

Use:

official carrier responsible for the current segment
→ exact raw event
→ official partner record
→ merchant account
→ universal tracker

Do not describe a broader or slower platform as dishonest merely because its update differs.

Tracking data health and shipment progress are different

Two separate systems can fail independently:

physical logistics
and
tracking-data publication

Data problem without physical delay

A parcel can be delivered while:

  • event transmission is delayed;
  • delivery data is incomplete;
  • corrected events are republished later.

FedEx’s documented April 2026 incident is an official example of successful physical delivery alongside delayed or corrected event data.

Physical delay without data failure

A tracking system can publish accurately while the shipment is:

  • waiting;
  • delayed;
  • held;
  • misrouted;
  • under customs review.

Therefore:

Estimated delivery dates are predictions, not scans

An estimated or scheduled delivery date is a calculated future outcome.

It is not a physical tracking event.

A carrier estimate can use some combination of:

  • origin;
  • destination;
  • service level;
  • acceptance time;
  • route;
  • latest events;
  • historical performance;
  • holidays;
  • customs;
  • network conditions;
  • capacity;
  • partner information.

Not every carrier publishes its exact prediction model.

Event and estimate answer different questions

Element Question answered
Latest event What was recorded?
Current status What broad stage is displayed?
Estimated date When does the system currently predict delivery?
Delivery window What interval is currently predicted?

Critical boundaries

FedEx’s tracking API exposes estimated delivery data separately from scan events. USPS distinguishes expected dates or windows from guaranteed services. DHL explains that delivery estimates can depend on shipment information, address, holidays, customs, and transport availability.

Some premium services can have specific commitments.

Do not treat every estimated or scheduled date as a guarantee.

The complete delivery-date-change diagnosis belongs to a dedicated problem guide.

Customs tracking is a shared-system view

A customs milestone can involve several actors:

  • customs authority;
  • another regulator;
  • carrier;
  • postal operator;
  • broker;
  • sender;
  • importer.

The carrier can display the milestone while the government authority controls:

  • inspection;
  • admissibility;
  • assessment;
  • release.

A customs event does not automatically mean:

  • delay;
  • physical inspection;
  • seizure;
  • payment due;
  • recipient action.

The exact reason and responsible actor control the next step.

Repeated customs events can reflect different processing stages or updated data. Repetition alone does not identify the cause.

Use the specialized customs guides for:

  • routine processing;
  • unresolved hold;
  • explicit release;
  • post-release silence.

Partner and last-mile events have several evidence levels

A multi-carrier shipment can pass through:

partner selected
→ shipment data sent
→ parcel tendered
→ partner accepts parcel
→ partner processes parcel

Those stages are not interchangeable.

Partner assigned

A provider is associated with a future segment.

Data transferred

The partner receives electronic information.

Physical handoff

The parcel is transferred.

Item-level acceptance

The partner records receipt.

Stronger evidence

Accepted / In Possession / carrier facility event

is stronger than:

Partner Assigned / Information Received / Awaiting Item

A local tracking number can exist before physical acceptance.

The full carrier and local-number discovery workflow belongs to the last-mile guide.

What does Out for Delivery prove?

Out for Delivery confirms a carrier-defined final-delivery stage.

Depending on the carrier, it can mean:

  • prepared for local carrier delivery;
  • dispatched from local facility;
  • loaded onto delivery vehicle;
  • collected by courier.

It does not automatically prove:

  • delivery route order;
  • a successful attempt;
  • that the driver reached the address;
  • unconditional same-day completion;
  • exact delivery time.

Use the carrier-specific raw event and the dedicated Out for Delivery guide.

What does Delivered prove?

Delivered confirms that the carrier recorded a delivery outcome.

It does not automatically prove:

  • intended recipient personally accepted the parcel;
  • correct-address delivery;
  • no theft after delivery;
  • no later correction;
  • no mailroom, concierge, neighbor, agent, locker, or safe-location handoff.

Possible proof attributes include:

  • delivery location;
  • photo;
  • signature;
  • recipient or agent name;
  • locker;
  • geolocation.

Each proof type answers a different question and has different limitations.

Tracking is operational evidence.

It is not automatically a complete legal or factual resolution of a delivery dispute.

What can tracking reliably confirm?

When the exact official event says so, tracking can support that:

  • shipment data exists;
  • carrier recorded acceptance;
  • parcel was processed at a facility;
  • a customs milestone was recorded;
  • a partner was assigned;
  • destination carrier accepted the item;
  • final-delivery route began;
  • an attempt was recorded;
  • delivery outcome was recorded;
  • pickup occurred;
  • return event occurred.

The strength depends on:

  • source;
  • exact phrase;
  • responsible carrier;
  • service;
  • timestamp;
  • location;
  • reason;
  • action code.

What can tracking not confirm by itself?

A tracking history may not establish:

Exact current location

The parcel may have moved since the last recorded event.

Continuous movement

The parcel can move, wait, process, or transfer between events.

No movement

A scan gap does not prove the parcel stayed still.

Movement

A scan gap does not prove it continued moving.

Normal timing

A broad status alone does not prove whether timing is normal.

Physical possession from data-only events

A label, pre-advice, or partner assignment is not acceptance.

Personal receipt

Delivered is not always personal handoff.

Correct-address delivery

A photo, signature, location label, or coordinates can have evidentiary limits.

Hidden cause

A broad exception does not identify a reason that the carrier did not publish.

Future outcome

An estimate does not guarantee delivery.

Tracking does not independently decide:

  • contractual liability;
  • marketplace protection;
  • insurance;
  • refund;
  • payment dispute;
  • legal receipt.

Carrier-specific tracking models

USPS

USPS provides tracking for eligible services and publishes status-specific guidance.

Its visibility architecture uses machine-readable identifiers and can involve individual mailpieces and larger handling units.

Important boundaries:

  • pre-shipment data can appear before possession;
  • acceptance or in-possession wording is stronger;
  • expected delivery information is not universally guaranteed;
  • not every internal movement must appear publicly.

UPS

UPS describes conventional scans and RFID sensors as complementary sources of tracking history in its current U.S. network.

UPS also states that long-distance shipments can travel before the next destination-hub scan.

Important boundaries:

  • do not generalize RFID coverage to every carrier or shipment worldwide;
  • sensor visibility does not create universal continuous GPS;
  • official event detail remains more useful than a broad progress label.

FedEx

FedEx says parcels are scanned at selected points between pickup and delivery.

Its visibility products distinguish:

  • tracking status;
  • scan events;
  • estimated date;
  • delivery window;
  • event webhooks;
  • proof and delivered-location features.

FedEx’s 2026 incident notices also demonstrate that events can be delayed, corrected, duplicated during reprocessing, or republished.

Important boundary:

  • a late update is not automatically a late physical movement.

DHL Express

DHL Express can create a waybill and show Shipment Information Received before later operational events.

Its status system distinguishes stages such as:

  • shipment data;
  • pickup;
  • facility processing;
  • transit;
  • clearance;
  • exception;
  • destination facility;
  • delivery.

DHL Express semantics should not be applied to DHL eCommerce.

DHL eCommerce

DHL eCommerce says:

  • the merchant normally supplies the tracking ID;
  • not all shipments have a tracking ID;
  • the first event can appear after merchant handoff;
  • many services publish milestone tracking;
  • some services provide limited or no destination-country events;
  • the merchant can remain the contract partner for investigation.

Do not apply DHL Express timing or event rules to DHL eCommerce.

Canada Post

Canada Post Track displays the most current information available to its public system for trackable services.

Canada Post also distinguishes:

  • tracking number;
  • delivery notice number;
  • reference number.

Not every incoming international service includes Canada Post tracking.

The absence of a public record can reflect service visibility as well as shipment state.

How international postal tracking data moves

International postal tracking is not one continuous database owned by one carrier.

The UPU framework includes several data layers.

Item-level events

EMSEVT messages can carry defined item-level events for trackable postal items, including:

  • origin acceptance;
  • outward exchange;
  • customs stages;
  • destination processing;
  • unsuccessful delivery;
  • final delivery.

Item attributes and customs data

Postal systems can exchange item attributes and electronic customs information.

Item-to-receptacle relationship

PREDES data can link an item identifier to a postal receptacle such as a bag or container.

Dispatch and receptacle messages

Postal operators can exchange dispatch and receptacle information separately from item-level events.

Carrier transport messages

CARDIT and RESDIT can exchange consignment and receptacle information between postal operators and transport carriers.

Public implication

The postal network can know about:

  • item;
  • receptacle;
  • dispatch;
  • consignment;
  • transport;
  • customs attributes;

without exposing every layer as a public event for the item.

The full cross-border architecture belongs to the dedicated international-tracking guide.

Use this six-question method on any tracking page

1. Who published the information?

  • responsible carrier;
  • local partner;
  • merchant;
  • marketplace;
  • universal tracker.

2. What kind of element is it?

  • event;
  • parent status;
  • estimate;
  • action;
  • proof.

3. What is the exact wording?

Read the detailed event, not only the progress bar.

4. What does it confirm?

Examples:

  • data exists;
  • possession;
  • processing;
  • customs milestone;
  • assignment;
  • attempt;
  • delivery outcome.

5. What remains unknown?

Examples:

  • exact current location;
  • current movement;
  • normal timing;
  • personal receipt;
  • hidden cause.

6. Who controls the next action?

  • seller;
  • original carrier;
  • destination carrier;
  • broker;
  • customs authority;
  • recipient.

Use the compact model:

source
→ exact event
→ timestamp and location
→ strongest confirmed fact
→ missing evidence
→ responsible next action

Protect tracking evidence and personal data

A tracking history can expose more than a status.

Before sharing a screenshot or asking for help, remove:

  • full tracking number;
  • order number;
  • recipient name;
  • street address;
  • phone number;
  • email address;
  • barcode;
  • shipping label;
  • delivery photo;
  • signature;
  • GPS coordinates;
  • account details;
  • private carrier or merchant links.

A partial identifier is usually enough for a general discussion.

Do not publish a full tracking number to ask strangers where a parcel is. A valid public record can reveal shipment details or belong to another recipient.

For a dispute, preserve the unredacted evidence privately:

  • original carrier history;
  • partner history;
  • exact event wording;
  • timestamps;
  • screenshots;
  • proof-of-delivery files;
  • support case numbers;
  • later corrections.

Share the complete evidence only through the verified carrier, merchant, marketplace, payment provider, insurer, or authority that needs it.

When another guide is the right answer

Use a specialized guide when the main question is:

This page owns the tracking system and its evidence boundaries.

Keep public tracking events together in USTracking

You can save the shipment in USTracking to keep publicly available carrier and partner events in one timeline and receive explanations of recorded statuses.

USTracking can organize and interpret public tracking records.

It cannot:

  • access unpublished carrier data;
  • expose private internal scans;
  • create a tracking event;
  • correct a carrier event;
  • verify an unrecorded movement or handoff;
  • provide continuous GPS for every parcel;
  • determine a hidden cause that no source published;
  • contact a carrier, seller, broker, or customs authority;
  • change a shipment;
  • open an investigation;
  • guarantee an estimated date;
  • guarantee delivery.

Published related guides:

Additional planned guides cover:

Only eligible published pages should render as live links.

Official sources

USPS

UPS

FedEx

DHL

Canada Post

Universal Postal Union

Scope and limitations

  • This page explains how public package-tracking records are created, transmitted, displayed, and interpreted.
  • It does not diagnose a specific shipment or determine its live location.
  • Public tracking is generally event-based and should not be treated as continuous GPS unless the responsible carrier explicitly provides a separate eligible live-location feature.
  • A tracking identifier, label, shipment-information event, partner assignment, or local number does not independently prove physical possession.
  • Manual scans, automated barcode reads, sensors, carrier systems, postal messages, customs data, and partner feeds can all contribute to tracking visibility.
  • Not every operational observation becomes a public item-level event.
  • A displayed location normally belongs to the recorded event and is not automatically the parcel’s current location.
  • Event time, transmission time, processing time, and display time can differ.
  • A scan gap does not prove movement or no movement.
  • A parent status summarizes; the exact raw event usually provides stronger operational detail.
  • An estimated or scheduled delivery date is a prediction and is not universally guaranteed.
  • A Delivered event confirms a recorded carrier outcome but does not automatically prove personal receipt.
  • Carrier technology, sensor coverage, APIs, event taxonomies, and public tracking features can change before the next scheduled review.
  • This page does not allocate custody, legal liability, claim eligibility, compensation, fraud, theft, or contractual responsibility.
  • 11Tracking is independent and is not a carrier, postal operator, customs authority, broker, merchant, marketplace, or standards organization.

Last reviewed: July 22, 2026 Next scheduled review: October 20, 2026 Correction contact: contact form Evidence basis: Current official USPS, UPS, FedEx, DHL Express, DHL eCommerce, Canada Post, and Universal Postal Union materials, supported by the private page-specific research packet