All ten
WiesnScout logo

WiesnScout

Seconds-level availability monitor

Product, apps, API, data sourcing, operations

Live

Oktoberfest tables sell out months ahead, so the only real supply is cancellations — and they are gone in under a minute. WiesnScout watches all 19 tents continuously and pushes an alert within seconds of a table matching your date, tent and party size opening up. It is a race against every other refresher in Munich, which makes the whole product a latency problem rather than a UI one.

iOSAndroidWebPush alertsLive dashboard
19tents watched
secondsfrom opening to alert
92,642seats tracked
3platforms from one codebase

Screens

Key engineering

sub-minute change detectionself-healing schedulerfail-closed error semanticssnapshot diffingmulti-channel alert deliveryseasonal burst capacityoffline-persisted query cache

Under the hood

Architecture

An edge-resident watcher feeding an alert path, with detection, deduplication and delivery as separate stages so latency can be measured and bounded at each one. The apps are thin; the product is the pipeline behind them.

Data & state

Snapshots held at the edge and diffed against each other, coordinated per watched entity so two checks cannot both claim the same change. Clients keep a persisted cache, so the app is useful before the network answers.

Runs on

Edge infrastructure with scheduled execution and no origin server. Three client platforms from one codebase, updated over the air.

Operational risk

The dangerous failure is silence that looks like data — a failed check must never read as “nothing available”, because from the outside the two are identical and only one is safe to act on. Errors fail closed, and the scheduler supervises itself and raises an alarm about its own quiet rather than simply stopping. Capacity is seasonal: idle most of the year, peaking on a date everyone knows in advance.

Stack

Apps
React NativeExpoexpo-routerFlashListTanStack Querypersisted offline cacheexpo-notificationsOTA updates
Edge
Cloudflare WorkersHonoDurable Objectsscheduled jobsaudit logKV
Watching
resilient fetch layerchange detectionsnapshot diffingself-healing scheduler
Alerts
push notificationsmulti-channel deliverypriority levelsdeep links into booking
Web
ReactViteZustandvanilla live dashboard

What it took

  • Getting the data was the project. Availability is not published anywhere usable, so most of the work went into building a reliable, well-behaved way to observe it continuously without hammering anyone — and into proving the numbers are right before anyone is woken at 4am.
  • Failure must never look like availability. A bad response is an error, never “no tables”, and a failed check can never read as “everything vanished” — the two are indistinguishable from the outside and only one of them is safe to act on.
  • A dead watcher has to be loud. The scheduler supervises itself, falls back when part of the system goes quiet, and raises an alarm about its own silence rather than simply stopping.
  • Speed is the product. Detection, deduplication and delivery all have to finish in seconds; an alert a minute late is an alert about a table someone else already took.
  • Notifications go out on several channels at once, with higher priority for instantly bookable slots and a direct link into the tent's own booking page — no commission, no account, no middleman.