MBTA alerts log

Point-in-time view of the MBTA /alerts feed, backed by the temporal alerts_history table in Postgres and served by the serve binary in this repo.

Pick a timestamp with the picker below — or scrub through the timeline of recorded change events — and the active set of alerts re-fetches automatically. Use the filters at the bottom to narrow the view.

Manual timestamp

Active when Time picker mode is Manual. Pick a date/time.

Scrub timeline

Active when Time picker mode is Scrub. Fetches every distinct change-event timestamp in the window below and lets you step / play through them. The slider snaps to actual transitions only, so each tick is an instant where the active-alerts set was different from the one before it.

Change events in window: **** · Playhead: ****

Active alerts

Showing **** of **** alerts after filters.

Affected stops & routes

Stops named in the filtered alerts’ informed_entity lists, placed by their GTFS coordinates — plus the routes those alerts name, drawn as lines in their MBTA route colour. An alert that only names a route (with no specific stop) now shows up as its route line. Click a marker or line for the alerts affecting it; stop colour runs yellow → red with the highest alert severity at the stop.

Active-period timeline

The active_period windows declared by each alert that passes the filters above, drawn Gantt-style: alert_id on the y-axis, time on the x-axis, one bar per period. The x-axis auto-fits the data — it shrinks to just enclose the visible periods and the playhead, padded a little — as long as they all sit within a window 30 days back to 90 days ahead of the playhead. When a bound escapes that window — a 1970 epoch sentinel, a date years out — the axis falls back to that fixed window instead.

At the fixed window, bars are clamped to it and a ‹ / › marks a period continuing past an edge. ∞ always marks an open-ended period (end is null). An alert that declares no active_period still gets a row — a diamond on the playhead with a no active_period label — since it is active at the playhead but names no window.

Snapshot sampler fire_at times are overlaid as small circles on each alert’s row: open circle = pending, filled circle = done (successful), red filled circle = failed. Only jobs within the visible x-window are shown.

Sampler jobs

Planned /predictions + /schedules snapshot attempts for each alert whose effect closes a stop or cancels a trip (STATION_CLOSURE, STOP_CLOSURE, SUSPENSION, CANCELLATION). One <details> per displayed alert that has any jobs in prediction_sample_jobs; the summary tallies status counts, the open panel lists every job. Most rows are currently pending or skipped — the sampler will fill in snapshots as the fire times pass.