What is a competitor price monitor?

A small serverless system that keeps an eye on competitor prices so an owner doesn't have to. It checks a list of competitor product pages on a schedule, notices when a price moves meaningfully, and sends the owner a short alert — for example, 'Competitor X dropped product Y by 12%' — with the recent history. It only suggests; it never changes your own prices. It respects each site's rules and uses a gentle, low checking rate.

How much does it cost to run?

About $2.40/month at typical small-business volume (around 200 watched product pages). The fixed cost is essentially zero. The variable cost is dominated by the scheduled checks that fetch each page and read the price; Bedrock fires only when a page layout changes and the old reading rule stops working, plus once a month for the summary, so those are small slivers. At 1,000 watched pages the bill lands around $9.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with a Function URL for the snooze-and-mute endpoint, EventBridge Scheduler for the staggered check runs and deferred dispatch, DynamoDB on-demand for price history and alert state, S3 (with versioning) for the watch list and saved page snapshots, SES outbound and SNS for alerts, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) for re-reading a page when its layout changes and for the monthly summary. No API Gateway, no NAT Gateway, no always-on compute, no headless browser farm.

Where does the watch list live?

In a Google Sheet in a Drive folder you control. One row per watched page with product name, competitor, page URL, the field to read, a check rate, your own price for reference, and the owner email. A small drive-sync Lambda mirrors the sheet to S3 every 15 minutes; the monitor reads from S3 to keep Drive API calls predictable and to get S3 versioning for free.

Does the monitor use AI?

Sparingly. The scheduled check uses no AI — it's plain Python that fetches a page, reads the price with a saved rule, and compares it to the last reading. Bedrock Haiku 4.5 fires only when a page layout changes and the saved rule stops finding the price (it proposes a new reading rule for human approval) and once a month for the summary narrative. Most of the system is deterministic by design.

Does it ever change my prices?

No. The monitor only suggests. It watches competitor pages, notices a meaningful move, and tells the owner with context — the recent price history, the size of the move, and how it compares to your own listed price. Any decision about your prices stays with a person. There is no path in the system that edits your store, your catalog, or any price.

How does it stay polite to the sites it checks?

It checks gently. The default rate is once or twice a day per page, staggered so requests don't arrive in a burst. It honors a site's robots rules and any crawl-delay, sets a clear identifying user agent, backs off on errors, and never hammers a page that returned an error. A page that keeps failing is paused and reported in the weekly digest rather than retried in a tight loop.

Series · 7 parts Published May 24, 2026

Price monitor

A serverless monitor that keeps an eye on competitor prices so you don’t have to. It checks a list of competitor product pages on a schedule, notices when a price moves meaningfully, and sends the right owner a short alert — “Competitor X dropped product Y by 12%” — with the recent history. It only suggests; it never changes your prices. It stays polite to every site it checks. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A competitor price monitor on AWS for a few dollars a month

The whole system on one page — a page checker, a watcher, and a dispatch piece, plus the four moves they share for every watched page.
02

How a competitor page gets watched

Three lanes feed the watch list — the Drive sheet itself, a paste-a-link lane that reads a page once and proposes a row, and an hourly import for products tagged in your own catalog.
03

How a price move gets noticed

A scheduled check fetches each page, reads the price with a saved rule, compares it to the last reading and the threshold in the rules doc, and picks one of four moves: steady, first alert, repeat move, big swing. No model on the check.
04

How a price alert reaches the owner

Owner resolution per page, quiet hours, a daily cap so alerts don’t pile up, Slack DMs with full context, email fallback, and the four guardrails between the watcher’s chosen move and the actual alert landing.
05

How a price alert gets handled

Three actions on every alert: note (log a decision, keep watching), mute (silence this page for a while), and stop (drop the page from the list). The monitor never touches your prices. Every action is logged.
06

What the price monitor costs

A few dollars a month at SMB volume. The monitor checks gently, calls no models on the check, and only fires Bedrock when a page layout changes and on the monthly summary.
07

Engineering reference: the price monitor architecture

Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Lambda inventory, IAM scopes, the polite-fetch policy, EventBridge Scheduler config, and the DynamoDB schemas.

What is a competitor price monitor?: A small serverless system that keeps an eye on competitor prices so an owner doesn’t have to. It checks a list of competitor product pages on a schedule, notices when a price moves meaningfully, and sends the owner a short alert — for example, “Competitor X dropped product Y by 12%” — with the recent history. It only suggests; it never changes your own prices.
How much does it cost to run?: About $2.40/month at typical small-business volume (around 200 watched product pages). The fixed cost is essentially zero. The variable cost is dominated by the scheduled checks that fetch each page and read the price; Bedrock fires only when a page layout changes and once a month for the summary, so they’re small slivers. At 1,000 watched pages the bill lands around $9.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with a Function URL for the snooze-and-mute endpoint, EventBridge Scheduler for the staggered check runs and deferred dispatch, DynamoDB on-demand, S3 (with versioning), SES outbound and SNS, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) for re-reading a page when its layout changes and the monthly summary. No API Gateway, no NAT Gateway, no always-on compute, no headless browser farm.
Where does the watch list live?: In a Google Sheet in a Drive folder. One row per watched page with product name, competitor, page URL, the field to read, a check rate, your own price for reference, and the owner email. A small drive-sync Lambda mirrors the sheet to S3 every 15 minutes; the monitor reads from S3 to keep Drive API calls predictable and to get S3 versioning for free.
Does the monitor use AI?: Sparingly. The scheduled check uses no AI — it’s plain Python that fetches a page, reads the price with a saved rule, and compares it to the last reading. Bedrock Haiku 4.5 fires only when a page layout changes and the saved rule stops finding the price (it proposes a new reading rule for human approval) and once a month for the summary narrative. Most of the system is deterministic by design.
Does it ever change my prices?: No. The monitor only suggests. It watches competitor pages, notices a meaningful move, and tells the owner with context — the recent price history, the size of the move, and how it compares to your own listed price. Any decision about your prices stays with a person. There is no path in the system that edits your store, your catalog, or any price.
How does it stay polite to the sites it checks?: It checks gently. The default rate is once or twice a day per page, staggered so requests don’t arrive in a burst. It honors a site’s robots rules and any crawl-delay, sets a clear identifying user agent, backs off on errors, and never hammers a page that returned an error. A page that keeps failing is paused and reported in the weekly digest rather than retried in a tight loop.

All posts

Frequently asked questions

Other series