Always-on Amazon listing monitor
An unattended service that watches a client portfolio of Amazon listings around the clock and routes anomaly alerts to the right client's Slack channel. It catches variation break-ups, review manipulation, and pricing events hours before a human would notice.
- System
- A tick-based scheduler (1 tick = 15 minutes) that polls the Keepa API on a priority matrix and pushes structured Slack alerts. Runs unattended for weeks.
- Stack
- TypeScriptNodeSQLite (WAL)Keepa APISlack Block KitPino logging
- Validation
- Detection thresholds were tuned against historical Keepa data for known past incidents before going live; every alert carries the raw numbers so the human can verify the claim in one click rather than trusting the system's summary.
- Outcome
- Listing incidents that previously surfaced only when a client noticed lost sales are now caught within one to four hours, portfolio-wide, with zero recurring human effort.
The loop
human checkpoint
- schedule
Every 15-minute tick, a priority matrix (listing priority × alert priority) decides which ASINs are due — high-priority listings get checked every tick, low-priority every 4 hours.
- fetch
Each tick splits into an expensive batch (full offer data, ~5 API tokens per listing) and a cheap reviews-only batch (~1 token). ~1,260 tokens/hour covers a 200-listing portfolio without blowing the API budget.
Keepa API
- detect
Rule-based detectors compare against SQLite history. Review-count drops ≥20% signal a variation being unnested, spikes ≥50% suggest manipulation, plus deal start/end and coupon add/remove.
SQLite
- alert
Findings become Slack Block Kit messages routed to the owning client's channel, with the listing, the delta, and what to check.
Slack webhooks
- triage
A human account manager reads the alert and decides the response. Contact Amazon, adjust the listing, or dismiss.
why a human here The detectors are deliberately high-recall. A false alarm costs a minute of reading; a missed variation break-up costs a client weeks of review equity. So the system over-reports and a human, who knows the client context the system doesn't have, makes the call.
The problem
An agency team managed hundreds of Amazon listings across clients. Listings break silently: a variation family gets unnested and the reviews vanish, a competitor’s coupon undercuts a price, a deal ends without anyone re-upping it. Detection was “a client emails us,” and by then the damage was days old.
Design decisions worth explaining
Token economics drove the architecture. Keepa charges per data field, and full offer data costs 5× a reviews-only check. The scheduler treats API tokens as the scarce resource: every tick, it fills a budget with the highest-priority due checks, running cheap review scans far more often than expensive offer pulls. That’s what makes 24/7 coverage of 200 listings affordable. Roughly 1,260 tokens an hour instead of the naive 6,700.
State lives in SQLite with WAL, so the detectors always diff against real history rather than the last poll. A review count that erodes slowly still trips the threshold across a window, and a crash mid-tick can’t corrupt the ledger.
Alerts carry evidence, not conclusions. Each Slack message includes the before/after numbers and a direct link. The human never has to take the detector’s word for anything, which is what made the team trust it.
Where the human sits, and why
Triage is the one human step because interpretation needs client context no data feed carries. Is this coupon ours? Is that price drop a planned promotion? Everything upstream of that question is mechanically verifiable, so it gets no human attention at all.