The Signal · Special Edition · October 2026
Shut Down by the Meter
Published October 15, 2026 · By Justin Spencer Smith · Also on LinkedIn
Published off-cycle, on the day of the events it records.
On October 15, 2026, at approximately 3:24 PM Eastern, the hosted service behind Live Transit Detroit's live data stopped answering. Every path on the proxy — /healthz, /api/vehicles, /api/alerts, and the site root — returned HTTP 503 with the body {"error":"usage_exceeded"}. The host, Netlify, had quota-paused the site. The live feed was down for every visitor until it was rebuilt later the same afternoon. This special edition records what was shut down, why the meter ran out, what the service had already proven by the day it closed, and where things stand now.
What was shut down — and what was not
What was shut down is specific: the hosted live-data proxy and the public API endpoints it served. The Live Transit page drew its entire live layer — vehicle positions and service alerts — from that proxy, so at the pause the map stopped receiving live data. Everything else that lived on the same host went down with it, including the five-minute telemetry logger described below.
What was not shut down: this website and the Live Transit map itself. They are hosted on GitHub Pages, a separate system that was unaffected throughout. The site never closed, no page was removed, and the map's stops, routes, geometry, and journey planner — all of which run on published data served with the site — remained available. The shutdown was a data-service shutdown, not a site closure, and the distinction matters for everything that follows.
Why: the meter
The proxy ran on Netlify's Personal plan: $9 per month, upgraded on October 10, carrying a budget of 1,000 credits per month. Credits are consumed by the hosted work the site performs. Three standing loads drew against that budget continuously. First, the page itself: every open copy of the Live Transit page polled two proxy endpoints — vehicles every 60 seconds, alerts every 120 seconds — so proxy invocations scaled with the audience. Second, the telemetry logger: a scheduled function on the same Netlify site polled the same upstreams every five minutes and appended vehicle records to the transit-data archive that the empirical timing model is built from. Third, our own verification traffic, which was heavy that day. At approximately 3:24 PM the budget was exhausted and the host paused the site outright — not a degraded mode, a hard stop on every path.
The architectural contribution is ours and is stated plainly: the proxy design called its upstreams in response to page traffic, so its cost grew with the number of people using the map. A public service whose cost scales with its audience, running on a fixed monthly meter, has a known failure date; the only unknown is which day it lands on. It landed on October 15.
The telemetry stream's fate is the same lesson in a second form. Because the logger shared the host, it shared the pause: the JSONL event stream, the timing-model inputs, and the page's history overlay froze at the same moment. The logger was repointed to the rebuilt feed the same afternoon; its stream records the interruption as a bounded gap of 32 minutes 5 seconds, represented as a gap and never backfilled.
The day's second budget: DDOT's transaction cap
The same day carried a second, independent budget failure, upstream of us. DDOT's BusTime API — the source of DDOT vehicle positions and service bulletins — documents a default limit of 10,000 requests per day per key (Clever Devices, BusTime Developer API Guide, v3, §1.5). On October 15 the key returned the error "Transaction limit for current day has been exceeded," recorded in our own alerts file at 20:15 UTC. DDOT vehicles had read as zero from approximately 1:12 PM Eastern.
The cause connects directly to the design retired that day. Until October 15, the key's consumer was the same per-page-view proxy: it ran a 41-call pattern — 4 batched vehicle calls and 37 per-route bulletin calls — on every page-driven poll, so daily volume scaled with audience and reached the cap by early afternoon. The rebuilt feed is fixed-cadence by construction: one builder, one schedule, and a volume that does not grow with the audience. Even so, the arithmetic had to be faced honestly — 41 calls across 288 five-minute cycles is approximately 11,800 transactions per day, above the documented default on its own. Bulletin collection was therefore moved to an hourly sub-cadence, bringing the operating volume to approximately 2,040 transactions per day, inside the default cap.
A request to raise the cap — to 50,000 transactions per day, with 25,000 stated as acceptable — was sent to DDOT on October 15 and is now in DDOT's hands. DDOT live positions return with the provider's daily reset; the durable arrangement depends on that decision.
What the service had already proven
The shutdown arrived one day after the Live Transit Detroit series published a case study of the map's native journey planner, and the results stand independent of the hosting failure. The reference journey runs from Providence Hospital to Woodward & Warren, ready at 12:45 PM on a Thursday, computed entirely from DDOT's published schedule. The native optimum is the three-bus sequence 10-3-8: 57 minutes, arriving 1:42 PM. Measured against the same ready time, the fastest answers from the three external engines benchmarked — Google Maps, the DDOT trip planner, and Moovit — were all built on SMART buses and arrived at 1:55 PM, 1:59 PM, and 2:01 PM respectively. DDOT route 3, the middle leg of the native optimum, appears in zero of the 25 itineraries those engines returned.
| Engine | Fastest routing | Arrival |
|---|---|---|
| Live Transit Detroit (native, DDOT only) | DDOT 10 → 3 → 8 | 1:42 PM |
| Google Maps | SMART 710 → 462 | 1:55 PM |
| DDOT trip planner | SMART 710 → 462 | 1:59 PM |
| Moovit | SMART 710 → 462/461 | 2:01 PM |
The study behind the headline is larger than one trip. Across 259 departures spanning Thursday, Saturday, and Sunday service, the two-transfer winner's advantage decomposes exactly: the third bus does not add ride cost — its ride-and-walk component was lower in 259 of 259 instances — it relocates the wait to a faster connection. A generalization census then re-optimized 630 journeys (15 hub nodes, all 210 directed pairs, three departures) and measured every leg of every optimum by removing it and re-planning: 752 of 1,083 legs in optimal journeys are load-bearing at a margin of five minutes or more. Two-transfer optima hold 189 of those 752 load-bearing legs — 25.1 percent of them.
The visibility result is the finding with a boundary, and the boundary is part of the result. In the demonstration phase, external engines offered the exact native sequence in 7 of 8 instances — at rank 1 every time it was offered — whenever the optimum was direct or single-transfer. Two-transfer optima were surfaced in 0 of 5 engine measurements. The invisible class is the multi-transfer optimum whose connecting middle leg — route 3 in the Providence journey, route 31 in one demonstration instance — an engine must specifically construct. The Providence invisibility was real; the generalization phase establishes it as a property of that journey class, not of native computation generally.
Where things stand now
The product is DDOT and QLINE. SMART was removed from the map the same day (build 20261015-1502), a priority decision recorded in the Live Transit Detroit series' files: the map now carries all 37 DDOT routes and 5,124 DDOT stops, and the QLINE streetcar.
The QLINE streetcar remains fully live on the map in the interim. Its positions never depended on the shut-down host or on the DDOT key — the QLINE feed is a public GTFS-Realtime stream the rebuilt builder reads directly — and at last verification the feed carried 4 streetcars with current positions on the Woodward corridor. While DDOT live positions are dark, users are free to enjoy the QLINE in the interim: it is running, it is on the map, and it is live in the same sense it has always been.
The feed itself was rebuilt the same afternoon on infrastructure the Academy runs itself. A workflow in this site's own repository polls the upstreams every five minutes and publishes the live data as static files on the site; the page reads those files, and a small dispatch driver on our own machine holds the five-minute cadence after GitHub's scheduler fired zero scheduled runs on the first day. The telemetry stream was repointed to the same feed. A service degradation notice is also live on the page (build 20261015-1638): when a data source degrades, the page now states which source, since when, and what still works, instead of presenting silence as if it were an empty street. The public API documentation page records the retired proxy endpoints as retired, with the reason.
What remains open is DDOT live positions. As of publication they await the provider's daily reset, and the durable fix is the cap decision described above. Nothing in the current state is fabricated to cover that gap: the DDOT leg of the feed reports its actual state, and the map shows DDOT's scheduled service — every stop, every route, the planner — while the live layer is dark.
The close
The hosted public API that other tools and pages could call is retired, and this special edition is its record. We hope to be back in the future — with fuller live coverage than the map carries today — when the data arrangements allow it. That is stated as hope and intent, not as a promise and not with a date: the two failures recorded here were both, at bottom, arrangements that did not hold, and the next arrangement will be announced when it exists, not before. In the meantime the map is open, the planner is computing, the streetcar is live, and the work continues on infrastructure we run ourselves.
Canonical record and full technical detail: the Live Transit Detroit series and the Academy's publish logs, at detroitautomationacademy.com/live-transit-detroit/.
The Signal is the newsletter of Detroit Automation Academy — where Detroit builds what's next. If you know a young builder who should be in the room, send them our way.