Diagnose a shipment that is not updating

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.

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.

Conterminal also adds the conflict to the workspace Activity Feed. If the shipment is on your My Watchlist, the same conflict sends a deduplicated email. Both links open this paused-review strip; neither resolves or changes the tracking identity automatically.

1. 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.
2. 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.
3. Reject the provider. Provider is wrong; resume keeps your values and restarts tracking.
4. Fix it upstream first. If you corrected the order elsewhere, use Source already corrected; resume.

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, Crowley, 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.

Forcing a refresh and the cooldown

Look for the LongShorty tag attached to the current timeline step. Its refresh group starts with a refresh icon, then All, then one button per tracking source, such as Maher and ONE. Select All to check every source, or a single source to check only that one. Sources that do not fit move into a +2 button. At the final step the tag reads Tracking complete and offers no refresh. When your workspace cannot refresh, the buttons stay visible but do nothing. A paused identity conflict must be resolved before refreshing.

Each button shows its source's state, and reading it correctly saves a lot of pointless clicking:

Plain

Ready. Select it to check that source now.

Blue, with a counter

Checking now. The refresh icon becomes a seconds counter, such as :03, that starts at your click. Sources waiting their turn are dimmed.

Green

That source just finished. A cooldown fill follows.

Draining fill

Cooling down. The fill shrinks as the next allowed check approaches. Hovering shows when the source was last checked and when it can run again. All shows the fill only when every source is cooling.

Selecting a source that is cooling down or already checking queues nothing. The tag says when that source can run next. A failed check shows the failure in red; select the source again to retry.

A managed shipment can have several tracking sources behind it, and All 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.” Managed tracking pages offer the same source buttons and rapid refresh. A single source refreshes only that source; All also re-checks which sources the item is linked to.

Rapid refresh

When you are waiting on a change, such as a customs hold clearing, open the stopwatch at the bottom right of the tag. Choose the sources to watch and a duration of 15 minutes, 30 minutes, 1 hour, or 2 hours. The terminal is preselected because that is where holds clear. Rapid refresh checks the watched sources every two minutes, never faster than the manual cooldown. It stops when the time is up. If the shipment had a hold when it started, it also stops when the hold clears, and the tag says so.

A shipment has one rapid refresh at a time. Everyone viewing it sees the same one, and it keeps running after you close the page. While it runs, the stopwatch shows the minutes left, the tag shows the next check, and watched sources are underlined in orange. Open the stopwatch to add 30 minutes, up to four hours in total, or to stop. Each check is an ordinary manual check, so its status lines, cooldowns, and results read exactly like a check you start yourself.

Reading the refresh status line

While a refresh runs, the LongShorty tag's two status lines show what is happening, and the refresh icon becomes an elapsed counter. The wording names the source, such as APM, PNCT, eModal, Octopi, Maher, or ONE, and tells you which phase the worker is in. The counter starts at your click, includes time in the queue, continues when the check moves from one source to another, and keeps running until the updated shipment appears. An older provider request or cached result does not move that start time backward. When nothing is running, the first line shows the latest check time:

Requesting Maher check

“Request accepted.” Queued, not yet picked up. With several sources, the second line names the ones queued next.

Preparing eModal check

“Starting the search.” Picked up; the session is opening.

eModal check already running

“Joined the check in progress.” Someone else's run swept your container in. This is a good outcome, not a collision.

Reading Maher site

“Looking up MSCU1234567.” LongShorty is reading the source's site for this container. With several sources, each takes its turn and the line names the active one.

Using cached tracking

The saved result is still within the source's cache limit. The tag and banner show the same outcome, with the source's last check time and next eligible check when known. A cache hit does not mean a new provider check ran.

Saving Maher results

The provider results are being saved.

Updating shipment status

Provider checks have finished. Conterminal is saving the shipment status.

Loading updated shipment

“Applying Maher results.” The results are ready. Completion waits for the updated shipment details to appear on the page.

Updates are taking longer than expected

Your current details remain available while the page update is pending. Retry update requests another page update without starting another provider lookup.

Tracking ready to display

The results are ready. The second line says what holds them: “Close the dialog to show results” or “Return to this tab to show results.” A dialog that is no longer visible does not hold the update.

Checking shipment update delayed

Provider checks have finished, but the final shipment update could not yet be verified. The page retries that check without starting another provider lookup.

Manual container checks can start while background checks continue, when provider and worker capacity are available. Leave the page open while it says Updating shipment status. Finishing one provider does not finish a check that has other sources pending. The page checks again when you return to the tab and periodically while it is visible. It refreshes when shipment data changes and waits while you are editing a field or using a visible open dialog.

The activity banner keeps this shipment's manual check ahead of unrelated document intake, and briefly shows its completion. Source cards use Last checked for the provider snapshot time. Evidence updated refers to the retained evidence when no check time is available. A new check can leave older movement dates unchanged.

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.

Reading branded source panels and their attribution footers

Penn Terminals shows Current status unavailable when its latest cargo search has no matching result. A previous Ready observation remains in dated history and does not confirm current availability. Seaboard movement history can recover an earlier pickup. A generic export status alone does not confirm a return. ONE can also publish an estimated empty-return event. It remains in source history and does not confirm that the container was returned; use an actual gate event or the dated return EIR.

A verified HOLT Gloucester or Packer receipt for a later full export can close a managed import when it identifies the same container, follows its confirmed pickup, and belongs unambiguously to that import's return sequence. The shipment shows Returned with Return confirmed by subsequent export · FULL receipt. The date reads By the receipt date. The receipt keeps its FULL export classification; it does not establish a separate empty gate-in time. An earlier qualified empty-return event takes precedence when available.

On carrier shipment pages, retained evidence appears under Tracking sources. Each expandable row names its provider, source type, and check time. Other panel layouts include the carrier's or terminal's logo and a lifecycle chip reading ON WATER, ON RAIL, AT TERMINAL, RAIL RAMP, REVIEW, GATE OUT, DELIVERED, or GATE IN, and the facts that source reported.

Norfolk Southern (AccessNS) is a separate rail row alongside steamship-line evidence. Expand it for the saved train and waybill history and rail last free day when reported. Its Last checked time belongs to the AccessNS snapshot; a recent check can retain older movement dates. The row remains available after delivery or empty return.

Where a panel shows 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.

Crowley panels make the lifecycle distinction explicit. A load-on-vessel event can set ON WATER; an origin gate-in is labeled Origin activity only, and an assigned-to-booking event is Booking context. Do not read either of those historical rows as destination arrival.

For an import still at Maher, the source panel shows Maher reported demurrage, Demurrage days, and Charges observed on when LongShorty captures a matching charge inquiry. Read the balance with that date; it is a provider observation and can change. Not capturedmeans no charge inquiry is saved. Unavailable means the inquiry did not return a usable balance. Neither means $0.00. Carrier demurrage remains separate and reads Not reported by Maher. Capturing these amounts does not create a billing charge or record a payment.

A Maher return receipt marked cancelled stays in source history; it does not establish Gate In. A linked document does not override that cancellation. A later valid empty-return receipt can still establish Gate In after the shipment identity and evidence checks pass.

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.

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 LRD (Last Return Date) 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.

If you have the return EIR, use Upload Return EIRafter pickup and confirm the actual date printed on it. Uploading today does not mean the container returned today. Turkon's qualified EMPTY OFF HIRE or GATE IN EMPTY event can confirm the return before the receipt arrives; an event from another shipment or before the current pickup stays in history.

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.

Another cause is credentials. For 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

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.