Tracking & visibility

Diagnose a shipment that is not updating

A shipment that has stopped moving on screen is almost never one problem. It is one of four: no source is connected for that terminal, tracking is paused on an identity conflict, the container was never enrolled, or the provider itself is stuck. Work them in that order — the checks are fast and each one rules out a whole class of cause.

9 minute read · Updated July 27, 2026

LongShorty is the worker, not the parser.

LongShorty is the named worker that signs into terminal, rail, and steamship-line systems and writes what it finds back onto your containers. It has nothing to do with how an emailed PDF gets read. If the problem is that a delivery order came in with the wrong container number or the wrong terminal, that is a Document Review problem, and refreshing tracking will not fix it.

Start here: three questions

Open the shipment and read the header before you touch anything. The header carries a tracking-state label and a sync-state label, and between them they answer most of this article without a single click.

Tracking state: One of “Tracking on”, “Tracking conflict”, “Tracking off for this job shell”, “Historical LongShorty tracking”, or “LongShorty not tracking”. Anything other than “Tracking on” explains the silence by itself.
Sync state: “Last synced …”, “Final status saved …”, “Tracking complete”, or “Waiting for LongShorty sync”. A container that has never synced reads “Waiting for LongShorty sync” — that is an enrollment problem, not a stale-data problem.

Then ask, in this order: is a source connected for this terminal; is tracking paused on a conflict; is this container enrolled at all. Only after all three are clean is a manual refresh the right move.

Is a source connected for this terminal?

When a container is in a state where tracking should be running — on water, scheduled, at pier, or awaiting return — and no LongShorty data exists for it, the shipment page renders a LongShorty Tracking card with an amber Unavailable badge. That card is the diagnostic. It lists four values: Terminal, Adapter (or Not configured), Tracking (Enabled or Disabled), and Browser polling (Enabled or Off).

The headline on the card is one of exactly three sentences, and they mean very different things:

“No LongShorty adapter is mapped”: “This pickup terminal does not have a LongShorty adapter configured yet, so tracking cannot start for this container.” Nothing you do in your workspace changes this. The terminal needs an adapter, which is Conterminal work.
“Terminal tracking is turned off”: The terminal is mapped to an adapter, but LongShorty participation is disabled for it. If browser polling is still on, the card says so and adds that polling alone no longer enables LongShorty discovery — so a green polling row is not reassurance.
“Tracking has not been discovered yet”: The source is live and enabled; there is simply no active tracked-container row for this delivery order yet. The next discovery cycle or a manual sync should create one.

Whether your workspace owns the login for a source is a separate question, and it is a short list. Most sources need no credential at all. See connecting tracking adapters for which ones ask you for an account and which are public or Conterminal-managed.

Rail is thinner than people assume.

CSX is the only direct rail adapter. Most other rail milestones arrive secondhand from steamship-line sources such as ONE, Maersk, and MSC, so a rail move can be real and still not appear until the carrier publishes it. BNSF is a customer-credential rail source that is still in development: credentials can be stored, but runtime polling stays off until Conterminal activates it.

Is tracking paused by an identity conflict?

If the provider tells LongShorty that your container belongs to a different bill of lading than the one on this order — or that your bill of lading belongs to a different container — LongShorty stops rather than guessing. You get a red strip at the top of the shipment headed Tracking Paused: Identity Conflict, with a plain-language line such as “Provider says container MSCU1234567 belongs to B/L ABCD1234, but this order has B/L WXYZ9876.”

Underneath it reads “Detected n times · last seen time · LongShorty paused this tracking identity; no automatic correction was applied.” That last clause is the important one: nothing is being fixed in the background. The shipment will sit here until a person resolves it.

While a conflict is open, the header sync state reads Paused: identity conflict in red, the tracking state reads Tracking conflict, and the refresh control is hidden entirely. There is no point hunting for a refresh button — resolving the conflict is the only way forward.

Accept the provider. When the provider returned exactly one competing value, you get a single button such as Accept provider B/L ABCD1234 and resume. If the provider returned several candidates, no accept button appears.
Correct to a terminal value. Where a terminal reported its own bill of lading, you get one button per candidate, worded Correct source to eModal B/L ABCD1234 and resume.
Reject the provider. Provider is wrong; resume keeps your values and restarts tracking.
Fix it upstream first. If you corrected the order elsewhere, use Source already corrected; resume.

The resolution buttons render only for users who can edit tracking. Without that permission you see the conflict and the explanation but no buttons at all, and nothing on the page tells you that is why. Ask someone with tracking edit rights, or see why a page or control is missing.

Not every source can raise this review. Dole, Maersk, Hapag-Lloyd, OOCL, ZIM, and Turkon Line are the steamship lines that implement identity-conflict detection. ACL, CMA CGM, COSCO, DSV, Evergreen, MSC, ONE, Seaboard Marine, and Yang Ming are recorded as not returning the candidate values a conflict review needs, so a mismatch there surfaces as wrong or missing data rather than as a pause. Terminal and rail adapters do not participate at all.

Is the container enrolled at all?

“Tracking on” in the header means an active tracked container row exists. LongShorty not tracking means no row was ever created. Historical LongShorty tracking and Tracking complete mean the row existed and the container finished its lifecycle — that is not a fault, and no amount of refreshing will produce new events.

Tracking off for this job shell is a deliberate state someone chose. Tracking can be paused and resumed per container from the job shell's Manual Override dialog (Edit Job Shell in the actions menu), which shows a Tracking Control block with the current status, the adapter, and a Pause Tracking / Resume Tracking button. That toggle only appears when the row is active or paused; a completed row has no button.

If the container is genuinely absent from tracking and the terminal is supported, the fix is enrollment, not refreshing. See bringing a container into tracking.

Forcing a refresh and the cooldown

The refresh control is a small chip in the shipment header labeled REFRESH, and it is also offered as Refresh LongShorty in the actions menu. It is hidden when you lack permission, when tracking is off for the job shell, and when an identity conflict is paused.

The chip has four states, and reading it correctly saves a lot of pointless clicking:

REFRESH: Idle and available. This is the only clickable state.
Refreshing…: Queued or running. Disabled, with a spinning icon. Clicking again does nothing.
Refresh in 1:24: Cooling down, with a live countdown. Hovering shows “Cached. Next refresh at 4:07 PM.”
Retry: The last attempt failed. Hovering shows the failure detail. This state is clickable.

The manual cooldown is two minutes. The automatic one is not.

A manual refresh sets the next manual eligibility exactly two minutes out, which is what the message “Manual tracked refreshes are limited to once every 2 minutes” refers to. The automatic cadence is a different, much longer clock — typically an hour by default, and capped by policy between one minute and twenty-four hours. Review-site sources such as East Coast Warehouse pace themselves on a fifteen-minute freshness window instead. So “it has been two minutes and nothing changed” is expected; the provider itself has usually not published anything new in that window.

A managed shipment can have several tracking sources behind it, and one refresh fans out to all of them. There is a ceiling: if a shipment has more than twelve active lookup targets, the refresh is refused with “Managed tracking refresh has n active lookup targets; the manual limit is 12.”

Reading the refresh status line

While a refresh runs, the header replaces the sync label with a live status and an elapsed timer. The wording names the adapter — APM, PNCT, eModal, Octopi, Maher, or the generic word terminal — and it tells you which phase the worker is in:

Waiting for LongShorty to start: “Request accepted.” Queued, not yet picked up.
Preparing eModal check: “Preparing search.” Picked up; the session is opening.
eModal check already running: “Included in the active eModal refresh.” Someone else's run swept your container in. This is a good outcome, not a collision.
Reading eModal status: “Checking MSCU1234567.” The worker is on the provider's site now.
Saving results: “Updating this job shell.” Writing back.

The endings matter more than the middle. A successful run that changed nothing reports Checked just now, no newer terminal data and is explicitly not a failure: LongShorty reached the provider and the provider had nothing newer. A successful run that did change something reports Last synced just now, which the header holds for about a minute before falling back to a timestamp. A failure reports Terminal check failed. On a managed shipment with several sources you can also get LongShorty updated some tracking sources with a count such as 2/3 tracking sources complete · 1 failed.

Two endings look like problems and are not. “A newer LongShorty refresh already completed for this container” means your request was superseded by a fresher one — the data on screen is newer than the run you started. “Tracking subject is no longer available for refresh” means the tracked row was closed or deactivated while your request was in flight; re-check the tracking state rather than retrying.

Reading branded source panels and their attribution footers

Below the header, tracking evidence renders as branded panels — the carrier's or terminal's own logo, a lifecycle chip on the right reading ON WATER, ON RAIL, AT TERMINAL, RAIL RAMP, REVIEW, GATE OUT, DELIVERED, or GATE IN, and the facts that source reported.

Next to each logo is a small circled i. Hover it. That tooltip is the attribution footer and it is the single most useful control on the page for this problem. It reads one of:

“LongShorty last wrote Maersk SSL evidence: …”: A real event row was written at that time. This is the strongest form of provenance.
“LongShorty captured Maersk provider snapshot: …”: No event row; the timestamp is when the provider page itself was captured. The panel is showing what the provider said, not a milestone Conterminal derived.
“LongShorty captured …: timestamp unavailable”: Neither a written event nor a snapshot time is on record. Treat everything in that panel as unverified age.

These attribution timestamps are always rendered in US Eastern time, regardless of where you are or what your workspace is set to. If you work a West Coast port, the panel footer will look three hours off against your own clock. That is the format, not a data problem.

Review-site panels carry two timestamps instead of one, side by side: Latest provider update and Latest poll. The gap between them is the answer to “is it stale or is it just quiet?” A recent poll with an old provider update means Conterminal is checking and the site has not moved. The banner above the facts says it outright — one of Provider evidence is current, Provider evidence is stale, Provider freshness is unknown, Source degraded · showing last-known-good evidence, or No evidence in the latest response · showing last-known-good evidence. The last two mean you are looking at retained older evidence on purpose, not at live state.

On a review-site panel, pickup requirements are listed individually as Complete, Waiting, or Not reported, with the footer “Pickup stays blocked until every requirement is complete.” A container that is not moving because a requirement is outstanding is not a tracking failure — tracking is working and telling you the answer.

What LongShorty owns that you cannot hand-edit

Some fields are deliberately read-only because a source owns them. In the Manual Override dialog, the LFD Dates block shows LFD (Import) and Empty LFD (Return) as locked inputs with the note that direct edits are disabled and that these are LongShorty-owned operational fields — fix the source sync rather than overriding them.

That is the right instinct generally. If a date on a shipment is wrong, the question is which source published it and when, and the attribution tooltip answers that. Overriding a milestone locally would only hide the disagreement until the next sync overwrites it.

The one override that genuinely changes what LongShorty does is Return Terminal Override: the dialog states that LongShorty will poll the chosen terminal for gate-in evidence while the container is out. If empty-return evidence never arrives, an override pointed at the wrong yard is a real candidate.

When a provider needs a human

Some failures are not about your data at all. Several providers sit behind bot protection, and when a Cloudflare check, a Turnstile widget, a CAPTCHA, or a security-check page appears in front of the worker, LongShorty cannot proceed. Conterminal classifies this as a provider security challenge or a required profile bootstrap and raises an internal alert; the fix is for an operator to open that provider's browser profile on the LongShorty runtime host, clear the challenge, and let the next cycle run. Hapag-Lloyd has its own named bootstrap procedure for exactly this reason, and OOCL and Turkon Line are both documented as needing a dedicated browser session because plain requests get challenge pages back.

You cannot clear a provider challenge from Conterminal.

There is no button for this in your workspace and no message on the shipment that names it. What you will see is a run that keeps ending in Terminal check failed for one source while other sources on the same shipment update normally. That pattern — one provider failing repeatedly, everything else healthy — is the signal to escalate rather than keep retrying.

The other human-shaped failure is credentials. For the three sources your workspace supplies its own login for, a rejected or aged credential stops that source and only that source. Those messages live on the Tracking Adapters screen, not on the shipment, and are covered in connecting tracking adapters. One worth knowing: an eModal row reporting that its access token expired and will auto-refresh on the next sync is harmless and needs nothing from you.

Troubleshooting

The refresh chip is not there at all

Three causes, in order of likelihood: an identity conflict is paused (look for the red strip at the top), tracking is off for this job shell, or your role cannot refresh tracking. The control is hidden rather than disabled in all three cases, so its absence is information.

“Waiting for LongShorty sync” and it never changes

This container has never synced. It is an enrollment or source-coverage problem, not a stale-data problem. Check the LongShorty Tracking card for which of the three availability messages you are getting before doing anything else.

“Checked just now, no newer terminal data”

This is a success. LongShorty reached the provider and the provider had nothing newer than what you already have. Repeating the refresh will produce the same line. If you believe the terminal has moved the container, compare against the terminal's own site before escalating.

“Terminal check failed”

The run did not complete. Hover the Retry chip for the failure detail. A single failure is worth one retry; the same source failing repeatedly while other sources on the same shipment succeed points at a provider-side block or a credential, and should be escalated rather than retried.

“LongShorty updated some tracking sources”

A managed shipment where at least one linked source did not complete. The detail carries the count, for example “2/3 tracking sources complete · 1 failed”. The sources that did complete have written their data; you are not looking at a wholesale failure.

“Managed tracking refresh has 14 active lookup targets; the manual limit is 12.”

This shipment fans out to more sources than a single manual refresh is allowed to drive. Nothing was queued. Wait for the automatic cycle, or ask support whether the shipment is enrolled against more sources than it needs.

“A newer LongShorty refresh already completed for this container.”

Your request was superseded. Someone else's refresh, or an automatic one, finished after you queued yours. The data on screen is newer than the run you asked for; there is nothing to retry.

“Tracking subject is no longer available for refresh.”

The tracked row was closed or deactivated while the request was in flight. Read the header tracking state — if it now says “Tracking complete” or “Historical LongShorty tracking”, the container finished its lifecycle and there is no more data to fetch.

“This terminal does not have a LongShorty adapter configured.”

The pickup terminal has no adapter mapped, so there is nothing for LongShorty to sign into. Credentials cannot fix this and neither can re-enrolling. Contact support with the terminal name.

The panel timestamp is hours off from my clock

Attribution timestamps on branded source panels are formatted in US Eastern time for everyone. Convert before you conclude the data is stale.

The provider's own website shows a newer status than Conterminal

Check the attribution tooltip first. If it says “provider snapshot” rather than “last wrote … evidence”, Conterminal is showing a captured page rather than a derived milestone, and the capture may predate the change. If a refresh still does not pick it up, that is worth escalating with both timestamps.

Tracking is paused and there are no resolution buttons

The resolution actions render only for users who can edit tracking. The conflict text and the detection count are visible to everyone; the buttons are not. Ask a colleague with tracking edit rights to resolve it.

Escalating: exactly what to send

A tracking escalation is fast to answer when it carries the four facts that identify which of the four causes is in play, and slow when it does not. Send the container number and the shipment link; the header tracking state and sync state, word for word; the exact status or error text from the refresh, including the adapter name it used; and the attribution tooltip text from the branded panel that looks wrong, with its timestamp. If you compared against the provider's own site, say what it showed and when you looked.

Do not send credentials. Support never needs a terminal password to diagnose a stalled shipment, and cannot accept one by email.