Tracking & visibility

Look up terminals, lines, and vessels, and get alerts

Conterminal publishes open reference pages for terminals, steamship lines, and vessels. Any email address — customer or not — can subscribe to a page and get a daily digest when its empty-return acceptance or its published facts change.

10 minute read · Updated July 27, 2026

The directories at /terminals, /lines, and /vessels need no account and no sign-in. Alerts are the same: you give an email address, confirm it once, and manage everything from links inside the emails. Nothing about alerts is tied to a Conterminal login.

Public pages vs the app

Most entities have two pages that look similar and answer different questions. The public page is reference data about the facility. The signed-in page is that same reference data plus your containers.

Public — /terminals/<slug>: Gate hours, appointment link, contacts, cameras, vessel receiving schedule, and the empty-return acceptance grid, with a source link on every externally-sourced fact. Ends with an email-alert form and a “See your containers at this terminal” button that routes to the login page.
Signed in — /protected/terminals/<slug>: The same profile with a working-set overlay of your own containers at that terminal, and per-cell remarks on the empty-return grid. Those remarks are deliberately withheld from the public grid, so a status that looks bare in public may carry a caveat inside the app.

The signed-in equivalent of the whole directory is Entities. That page leads with counts — Active Delivery Orders, Companies You Work With, Terminals On File, Lines On File, Vessels Tracked — and then lists companies, terminals, lines, and vessels tied to your shipments. Use it when you want the entities you touch. Use the public directory when you want any facility in the catalog, published or not yet worked.

The two catalogs are not the same size and are not meant to be. Public entity pages exist only for entities that have been explicitly published; the signed-in console counts everything on file. A terminal you see inside the app can legitimately have no public page, in which case its name is plain text rather than a link.

Searching and faceting terminals

/terminals is the only directory with search. The whole published list is delivered with the page, so filtering is instant and never hits the network — but it also means the search only knows about the fields that are on the cards.

Type into Search terminals. The field is labeled Search terminals with the placeholder Name, city, state, port, or operator. Matching is case-insensitive substring matching across exactly those five values. A UN/LOCODE, a FIRMS code, or a SCAC will not match.
Narrow with the facets. Three groups appear below the search box: State, Port / gateway, and Terminal type. Each button shows a count. Selecting one in each group narrows the list further; selecting the same button again clears it.
Read the count line. Above the results you get Showing 4 of 11 terminals or similar, plus a Clear filters link once anything is active. With nothing matching you get “No terminals match the current search and filters.”

Facet buttons and their counts are derived once from the full list and do not change as you type. A facet button can therefore show a count of 6 while the visible list shows 1, because the count describes the whole catalog and not the filtered view. It is not a bug, but it will mislead you if you read the counts as “remaining.”

A terminal only appears under Port / gateway or Terminal type when that classification is actually known for it. Conterminal leaves those blank rather than guessing, so a facility with an unconfirmed classification is reachable by search and by State, but is filtered out the moment you press a gateway or type button. If you cannot find a terminal you know exists, clear the facets and search by name.

/lines and /vessels have no search box and no facets — they are plain alphabetical card grids. Use your browser's find-in-page there.

Reading a terminal profile

Terminal pages come in two shapes behind the same URL, and knowing which one you are on saves you from hunting for a section that was never there.

Curated operational profile: The deeply-covered terminals. Structured gate hours, appointment status, phone and email contacts, terminal cameras, a vessel receiving schedule, a live empty-return acceptance grid, and an email-alert form.
Directory reference profile: The broader national set. Coordinates and coordinate basis, facility codes (UN/LOCODE, FIRMS code, SPLC, serving railroads), official links, facility notes, and FAQ — no structured gate-hours table, and no email-alert form on the page.

Gate hours

On a curated profile, gate hours render as three rows — Mon–Fri, Sat, and Sun — and any day with no published value is simply omitted rather than shown as closed. Underneath sits Verify with the terminal: and a link to the operator's own site. Treat that link as the authority; the page is a convenience copy. A directory profile has no hours table at all; it offers a Gate hours link under Links & systems instead.

The Appointment block always renders, and reads either Appointment required or No appointment required, followed by a Make an appointment link when the operator publishes one.

Receiving schedule

The Receiving schedule table carries one row per vessel call with the columns Vessel / Voyage, ETA, Begin receiving, Cargo cutoff, Hazmat cutoff, and Reefer cutoff. Vessel names link through to the vessel page when that vessel is published. The whole section is hidden unless Conterminal can point at the terminal's own schedule page as the source, so its absence means “no attributable source” rather than “no vessels.”

Empty-return acceptance

The grid puts steamship lines down the left and equipment classes across the top, with one status badge per cell and an em dash where the terminal publishes nothing for that combination. Above it are the source link and an As of timestamp. The page states the operating rule plainly: empty-return acceptance “changes daily. Always confirm same-day before dispatching a driver.”

Accepted: The terminal is taking that line and equipment class.
Restricted: Taking it under a limitation the terminal has published.
Conditional: Taking it only if some condition is met.
Not Accepted: Not taking it.
Unknown: A value was published but does not map to a known status.

When the underlying refresh falls behind, the grid prints “This terminal’s refresh is overdue — treat the statuses below as unconfirmed and verify same-day before dispatching.” The badges keep rendering their last known values, so a stale grid looks exactly like a fresh one apart from that one line. Read it before you act on the grid.

Where a terminal publishes no acceptance page of its own, the section stays but the grid does not, and the page says the terminal “does not currently publish an operator-owned public empty-return acceptance page. Confirm acceptance with the terminal or your steamship line directly.” The grid is refreshed by LongShorty, the worker that signs in to terminal systems on Conterminal's behalf; every status change it observes is also what feeds the alert emails below.

Subscribing an email to alerts

The subscribe form sits near the bottom of a published terminal, line, or vessel page, headed Get alerts for <entity name>. It describes itself accurately: “Free email alerts for empty-return acceptance changes and page updates. One confirmation email, then at most one digest a day.”

Enter an address in Email address and select Get email alerts. The button reads Sending... while it works.
The form is replaced by Check your email to confirm. and “We sent a confirmation link. Once verified, you’ll get a daily digest of changes for <entity name>.”
Open the email from Conterminal Alerts, subject Confirm your Conterminal email alerts, and select Confirm your email.

Every subscription is created with both alert kinds switched on, and there is no per-kind choice anywhere in the interface:

Empty-return changes: A status flip, a newly listed line/equipment pair, or a pair disappearing from a terminal's acceptance grid. Produced by diffing the grid before and after each LongShorty refresh cycle, so it fires on what a viewer would actually see change.
Page updates: A substantive republish of the entity's own profile facts. Content-addressed, so republishing byte-identical content produces no alert, while a genuine edit on the same day does.

An empty-return change produces alerts for both sides of the change — the terminal and the steamship line — so subscribing to a line and to a terminal it calls will show you the same change twice, once under each heading.

“Check your email to confirm.” means the request was accepted, not that an email was delivered. The verification send is deliberately fail-soft: if the mail provider rejects or defers it, subscribe still reports success and the failure is only visible in server logs. There is no delivery queue behind it — the retry is you submitting the form again, which mints a fresh link. If no email arrives within a few minutes, check spam, then resubmit once. Do not hammer it; you get five subscribe attempts per hour per address.

An address that is already confirmed gets no email when you subscribe it to another entity — there is nothing left to verify, so the new subscription is simply live. That is why the second and third entity you add feel silent compared with the first.

Verifying and managing subscriptions

The confirmation link lands on /alerts/verify, headed Confirm your email. Success shows Email confirmed — “You’re verified. You’ll get a daily digest of changes for the entities you follow.” The link is single-use; clicking it again gives Link already used with “This link isn’t valid anymore. If you already confirmed this email, you’re all set — no further action is needed.” That is not an error.

Once verified, you receive at most one digest per day, sent daily at 11:00 UTC — roughly 6–7 a.m. US Eastern, just after the business-day boundary the digest window is anchored to. Its subject counts the changes, for example 3 updates on your Conterminal alerts, and it is headed Your daily digest with one block per entity. A day with no changes produces no email at all, so silence is the normal state.

Digest summaries quote the underlying status values rather than the badge labels on the page — you will read “changed from accepted to not_accepted” in the email where the grid shows Accepted and Not Accepted. Same data, rawer wording.

The manage page

/alerts/manage is reachable only through the Manage your alerts link in an alert email — there is no login and no way to request the link from the site. It opens on Manage your alerts, shows Signed in as with your address masked to something like j***@example.com, and lists Your subscriptions (3/20) with a Remove button per row.

Remove one entity. Select Remove on its row. This affects that entity only; the rest of your subscriptions and your confirmed address are untouched.
Add one. Under Add a subscription, choose an Entity type — Terminal, Steamship line, Vessel, or Company — enter the Entity slug, and select Add.
Get the slug from the URL. It is the last path segment of the entity's own page. Open the page and copy what follows /terminals/, /lines/, or /vessels/.

Do not trust the slug example.

The Add form's hint offers conterminal.com/terminals/newark-nj as the model. Real terminal slugs carry a generated suffix — for example apm-terminals-fyv1yt — so a slug typed from that example will not match anything. Worse, the form does not check the slug against a real entity: a typo is accepted, consumes one of your 20 slots, and then never produces an alert. Always copy the slug out of the address bar.

The manage link is a one-shot capability that rotates every time you add or remove. Only the link in your most recent alert email works. If you add or remove from a page you left open, keep using that same tab — it rewrites its own URL with the new token — and do not go back to the older email. An expired one shows Link no longer valid: “This management link has expired or was already used elsewhere. Use the link from your most recent alert email.”

Unsubscribing

There are three ways out, and two of them are all-or-nothing.

Your mail client's Unsubscribe button. Both the confirmation email and the digest carry a standard one-click unsubscribe header, so Gmail and Outlook render their own Unsubscribe control. One click stops everything.
The Unsubscribe link in the email footer. It opens /alerts/unsubscribed and reports You're unsubscribed — “You won’t receive any more alert emails from Conterminal for any entity. You can subscribe again any time from a terminal, line, or vessel page.”
Unsubscribe from all alerts on the manage page. The button sits below the list and asks to confirm first: “Unsubscribe from all alerts? You can subscribe again anytime from a terminal, line, or vessel page.”

None of the three is per-entity. All of them stop every alert for that address, for every terminal, line, vessel, and company at once. To stop alerts for a single entity, use Remove on the manage page instead.

Clicking an unsubscribe link twice — or having your mail client prefetch it — reports the same success page rather than an error, which is intentional. Resubscribing later from any entity page reactivates the same address and does not make you confirm again if you already had; your previous subscription list survives, so check the manage page after resubscribing rather than assuming you are back to zero.

The per-address entity cap

One email address can follow 20 entities. That is a single pool shared across terminals, lines, vessels, and companies — not 20 of each. Subscribing to something you already follow is a no-op and does not consume a slot.

The limit surfaces with different wording depending on where you hit it. From an entity page's subscribe form: “That email has already reached the 20-entity alert limit. Manage subscriptions from the link in any alert email, or use a different address.” On the manage page the Add form is replaced entirely by Subscription limit reached — “You’ve reached the 20-entity limit. Remove one above to add a different entity.”

If you are at the cap and the only manage link you have is old, you are stuck: you cannot remove anything without a working manage link, and the subscribe form will keep rejecting you. Wait for the next digest to get a fresh link, or use a different address.

Rate limits

Every alerts action is throttled on a one-hour rolling window. All of them return “Too many requests. Please try again later.” from the server; the pages render it as Too many attempts with “Please wait a few minutes and reload this page.”

Action	Limit per hour	Counted by
Subscribe	20	Your connection
Subscribe	5	The email address you typed, from anywhere
Verify	20	Your connection
Manage (load, add, remove)	30	Your connection
Unsubscribe	30	Your connection

The five-per-hour email limit is what a shared office IP will hit first when several people subscribe the same distribution address.

Troubleshooting

“That email has already reached the 20-entity alert limit.”

The address follows 20 entities. Open the manage link from your most recent alert email and remove one, or subscribe a different address. Note that a mistyped slug added on the manage page still occupies a slot even though it produces no alerts — check the list for entries that do not look like real slugs.

“Too many requests from this connection. Try again in a few minutes.”

The subscribe endpoint allows 20 attempts per hour from one connection and 5 per hour for one email address, whichever you hit first. Wait it out. Repeated submissions do not queue and do not make the verification email arrive sooner.

“Too many attempts” on the verify, manage, or unsubscribe page

Same one-hour throttle, applied per connection: 20 for verify, 30 for manage, 30 for unsubscribe. Wait a few minutes and reload the page — do not open the link repeatedly, because each attempt counts.

A company alert link makes me sign in

Company subscriptions are supported, but companies have no public page. Their alert and manage links point at /protected/companies/<slug> inside the app, so an unauthenticated click lands on the login page first. The destination is preserved, so signing in takes you straight to the company page. If you have no Conterminal account, that link is not usable — subscribe to a terminal, line, or vessel instead.

I confirmed my email but no digest ever arrives

A digest is only sent when at least one of your entities changed during the window; a quiet day sends nothing. Confirm your list on the manage page first — a slug typo silently produces nothing forever. If your entities visibly changed on their public pages and you still got no email, contact support.

“Missing management link” or “Missing verification link”

You opened /alerts/manage or /alerts/verify without the token that has to be in the URL. These pages cannot look you up by address. Go back to the alert email and click the link rather than typing the address by hand, and do not truncate the query string when copying it.

“This management link has expired or was already used elsewhere.”

The manage token rotates on every add and remove, so an older email's link stops working as soon as you make a change. Use the link from your most recent alert email. If you have not received one since, you have no working link until the next digest.

The terminal page has no email-alert form

You are on a directory reference profile rather than a curated operational profile. Those pages carry facility codes and official links but no subscribe form. You can still follow the terminal by adding its slug on the manage page, if you already have a working manage link from another subscription.

The acceptance grid looks wrong or has not moved

Check the As of timestamp and look for the overdue-refresh line above the table. A stale grid keeps showing its last known statuses. Empty-return acceptance changes daily — confirm same-day with the terminal or the steamship line before dispatching a driver, regardless of what the grid says.

“Couldn't reach the alerts service. Please try again later.”

The request never completed — a network problem or a service outage, not a rejected subscription. Nothing was recorded, so retrying is safe once you have a connection again.