Seattle–Tacoma · public record

Terminal State Archive

What this tool does

What it is. Pick a terminal, your box, and the days on the invoice. For each day, the tool shows what the terminal itself had published about its own state, from copies saved at the time: whether the gate was scheduled open, whether it was accepting your line's empties, what notices were in force, and (once the channel exists) whether appointments were available. It does nothing else.

Where it comes from. Public pages of the Northwest Seaport Alliance and the terminal operators, fetched on a schedule, stored unchanged with a UTC timestamp and a SHA-256 hash, and never overwritten. The tool holds what the terminals published about themselves; it has no per-container data.

Pick a terminal, your box, and the days on the invoice. This shows what the terminal itself had published about its state on those days, from copies saved at the time. Unknown means no saved copy, not that nothing was wrong.

Days to check

Days to check

What it is. The days you want the record for, usually the days a demurrage or detention invoice is charging. Narrow a day to a time window if it matters; leave it all day otherwise. The tool looks up what the terminal had published for each day.

Where it comes from. The invoice's free-time and charge dates, or your own records.

ALL DAY
Where the record comes from

Loading…

How the record is stored and turned into this table

1. Fetch and keep, unchanged

On a schedule (every 15 minutes to two hours, depending on the page) a small program requests each page exactly as a browser would, identifying itself with a contact email. The response body is written to disk as-is, named by its SHA-256 hash (data/raw/8f/8fc336…html), and one row is added to a captures table: which page, the UTC time, the HTTP status, the hash. Rows are only ever added; nothing is edited or deleted, and an unchanged page is still recorded so it is provable that the page said the same thing at that time. If the fetch fails, the failure is recorded too.

2. Read facts out of each copy

A parser per page turns the HTML into rows in a second table, parsed_rows, each tied to the capture it came from. This table is derived and can be rebuilt from the raw copies at any time. The kinds of row are: a gate day (terminal, date, open or closed, hours), an empty rule (terminal, line, container size, drop or pick, accepted yes or no), a notice (a paragraph with an operational keyword and any dates it mentions), an export receiving window (vessel, first receiving date, cutoff), and a turn-time reading (queue and in-terminal minutes, or N/A). Anything the parser cannot classify is kept as a generic table row so nothing is lost. A parser that fails leaves the raw copy untouched and logs the error.

3. Answer the questions for one day

For each day you ask about, the table is built like this:

  1. Gate scheduled open? — every gate-day row whose date is that day, from every capture that asserted it. If two captures disagree (the terminal changed the schedule), the latest is shown and the change is flagged.
  2. Empties accepted for your box? — the empty rules from the most recent capture taken on or before that day, filtered to your line and size. The answer follows the drop-off rules, since returning an empty is a drop; pick-up rules are listed beside it. A rule carried forward from an earlier day says so.
  3. Closure or restriction noticed? — notices posted that day, or whose text mentions that day, from the port's bulletin page and the terminal's own page.
  4. At the gate — the port's truck turn-time readings taken that day, narrowed to your time window if you gave one. They do not depend on anyone having posted a notice, so they are the record of closures and congestion nobody announced.
  5. Appointment available? — not answered yet. The archive has no access to the appointment system, so this column is left out.

Every cell lists the capture it was read from. A day with no capture for a question says unknown. The archive holds what the terminals published about themselves; it has nothing about individual containers.

What each page actually gives us

Terminal update pages (NWSA site, one per terminal): a two-week gate-hours table, an empty-return matrix by line and size, and notice paragraphs. These feed the first three columns directly. Husky and PCT write their empty rules as prose rather than a matrix, so for them the empties column is unknown and the rules appear as notices instead.

WUT empty receiving (WUT's own site): a dated yes/no matrix by line and size. Feeds the empties column for WUT.

NWSA trucker news: dated bulletins. Feeds the notices column for every terminal.

Export receiving dates (NWSA and WUT): vessel cutoffs and first-receiving dates. Captured and parsed, but not used in this table; they belong to the export side of the story.

Cameras & truck turn times (NWSA): what you see on that page is webcams plus two numbers per terminal, queue minutes and in-terminal minutes, averaged over the last hour from RFID tags on the trucks. Those two numbers are not in the page's HTML; a script fills them in after the page loads, from a live feed. Our capture gets the HTML before that script runs, so it contains the placeholders ("N/A … Connecting") and nothing else. We keep those copies because they prove what the page served, but they carry no numbers, which is why there is no congestion column in the table. Capturing the numbers means reading the feed behind the page, which is on the list.

Raw copies: click a hash to view a capture with scripts disabled, or ↓ to download the original bytes and check them with shasum -a 256.