---
id: 019cb9fd-149a-7785-96a1-dcc78bc14393
name: Station Bottleneck Monitor
kind: Anomaly
cron: 0 0 * * * *
analysis_window: 1h
comparison_periods: [1d, 7d]
---

Detect when a single KDS station has a bottleneck -- items routed to that station take dramatically longer while other stations remain normal.

## Known Tables & Columns

### `curated.kitchen_orders`
- `guid` (varchar, PK) - order identifier
- `store_guid` (varchar) - which store/restaurant
- `preparation_time` (int, seconds, nullable) - total order preparation time
- `done` (tinyint) - whether the order is complete
- `is_deleted` (tinyint) - soft delete flag
- `create_time` (int, unix timestamp) - when the order was created

### `curated.kitchen_order_items`
- `guid` (varchar, PK) - item identifier
- `order_guid` (varchar, FK) - parent order
- `name` (varchar) - menu item name
- `category` (varchar) - Grill, Fryer, Salads, Drinks, Desserts
- `device_id` (int) - KDS station ID (1=Grill, 2=Fryer, 3=Salad, 4=Drinks, 5=Desserts)
- `preparation_time` (int, seconds, nullable) - how long the item took to prepare
- `is_deleted` (tinyint) - soft delete flag
- `create_time` (int, unix timestamp) - when the item was created

### `curated.kitchen_item_status_events`
- `guid` (varchar, PK) - bump identifier
- `item_guid` (varchar, FK) - parent item
- `status` (tinyint) - 0=pending, 1=prepared, 2=done
- `prepared_local_time` (int, unix timestamp, nullable) - when item was prepared
- `done_local_time` (int, unix timestamp, nullable) - when item was completed
- `is_deleted` (tinyint) - soft delete flag

## Analysis Approach

1. Query the last {AnalysisWindow} of items from `curated.kitchen_order_items` (`is_deleted=0`, `preparation_time IS NOT NULL`), joined with their parent orders from `curated.kitchen_orders` (`done=1`, `is_deleted=0`).
2. Group items by `device_id` (station) and by hour.
3. For each station-hour combination, verify at least **10 items** exist. Ignore stations with fewer data points.
4. For each station-hour combination, compute the average and standard deviation of `preparation_time`.
5. Compare each station's hourly average against its own historical baseline (same station, same hour-of-day, {ComparisonPeriods}).
6. Look for the **asymmetric pattern**: one station shows a massive spike (5x+ normal) while other stations remain within normal range.
7. The key differentiator from a "slow kitchen" anomaly is that only ONE station is affected. If multiple stations are elevated, this is likely a different issue — call `emit_no_anomaly`.

## Station Reference

- `device_id = 1` : Grill (burgers, chicken, steaks -- baseline 300-660s)
- `device_id = 2` : Fryer (fries, tenders, onion rings -- baseline 180-660s)
- `device_id = 3` : Salad (salads -- baseline 120-360s)
- `device_id = 4` : Drinks (beverages -- baseline 30-240s)
- `device_id = 5` : Desserts (desserts -- baseline 60-420s)

## Severity Guidance

- **Low**: One station 5-8x above its baseline, others normal
- **Medium**: One station 8-12x above its baseline, causing visible order delays
- **High**: One station >12x above its baseline, orders backing up significantly