What is a shipping notifier?

A small serverless system that watches each order's shipping status and keeps the customer in the loop without anyone lifting a finger. As an order moves from placed to shipped to out for delivery to delivered, it sends the right friendly update at each step. If a delivery starts running late, it warns the customer and the owner early. It cuts down 'where is my order?' emails, respects quiet hours, and never double-sends the same update.

How much does it cost to run?

About $2.40/month at typical small-business volume (around 300 orders a month). The fixed cost is essentially zero. The variable cost is dominated by the emails sent and the regular checks that look for status changes. Bedrock fires only when a forwarded carrier email needs reading and once a month for the summary, so it stays a small sliver. At 3,000 orders a month the bill lands around $14.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with Function URLs for the carrier webhook and the unsubscribe link, EventBridge Scheduler for the regular status check and deferred sends, DynamoDB on-demand, S3 (with versioning), SES inbound + outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) for reading forwarded carrier emails and the monthly summary. No API Gateway, no NAT Gateway, no always-on compute.

Where does the order list live?

In a Google Sheet in a Drive folder you control. One row per order with order number, customer name, customer email, carrier, tracking number, current status, last-updated date, and a link to the order. A small drive-sync Lambda mirrors the sheet to S3 every few minutes; the notifier reads from S3 to keep Drive API calls predictable and to get S3 versioning for free.

Does the notifier use AI?

Sparingly. The regular check uses no AI — it's plain Python that reads each order's tracking status and decides which update to send. Bedrock Haiku 4.5 fires only when somebody forwards a carrier email that the webhook missed (it reads the email and proposes a status change for one-tap approval) and once a month for the summary narrative. Most of the system is deterministic by design.

How does an update reach the customer without being annoying?

Each status sends exactly one update — shipped, out for delivery, delivered, delayed. The notifier writes down every send so it never repeats one. Updates respect quiet hours (default 9pm–8am local) so nobody gets a 2am email. A customer can unsubscribe from any update with one tap. And the same order never gets two 'shipped' emails even if the carrier reports the same status twice.

What happens when a delivery runs late?

Each order has an expected delivery date. If the order passes that date without a delivered status, the notifier marks it delayed, sends the customer a warning with what it knows, and tells the owner so a human can chase the carrier before the customer has to ask. Every delay is recorded in the sn-audit DynamoDB table with the order, the date, and what was sent, so the trail is auditable later.

Series · 7 parts Published May 20, 2026

Shipping notifier

A serverless notifier that watches each order’s shipping status — placed, shipped, out for delivery, delivered, delayed — and sends the right friendly update at every step, so the customer is always in the loop and nobody on your team has to lift a finger. When a delivery runs late, it warns the customer and the owner early. It cuts “where is my order?” emails, respects quiet hours, and never double-sends. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A shipping notifier on AWS for a few dollars a month

The whole system on one page — an order intake, a notifier, and a sender, plus the updates they send for every order as it moves through each shipping step.
02

How an order gets watched

Three lanes feed the order list — the Drive sheet itself, a carrier webhook that posts tracking updates, and an inbox-forwarding lane that reads forwarded carrier emails into proposed status changes for one-tap approval.
03

How a shipping update gets sent

A regular check reads the order list, looks at each order’s status, compares it to what was last sent, and picks one of five moves: nothing, shipped, out for delivery, delivered, or delayed. No model on the check.
04

How a message reaches the customer

Contact resolution per order, quiet hours, unsubscribe checks, a friendly email with tracking, and the four guardrails between the notifier’s chosen move and the actual update landing.
05

How a late delivery gets caught

Three things happen when an order passes its expected date: warn the customer, alert the owner, and log the delay. Each one updates the order list and writes an audit row so nothing slips silently.
06

What the shipping notifier costs

A few dollars a month at SMB volume. The check runs on a schedule, calls no models, and only fires Bedrock on forwarded carrier emails and the monthly summary.
07

Engineering reference: the shipping notifier architecture

Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Lambda inventory, IAM scopes, the carrier webhook flow, EventBridge Scheduler config, and the DynamoDB schemas.

What is a shipping notifier?: A small serverless system that watches each order’s shipping status and keeps the customer in the loop without anyone lifting a finger. As an order moves from placed to shipped to out for delivery to delivered, it sends the right friendly update at each step. If a delivery starts running late, it warns the customer and the owner early. It cuts down “where is my order?” emails, respects quiet hours, and never double-sends the same update.
How much does it cost to run?: About $2.40/month at typical small-business volume (around 300 orders a month). The fixed cost is essentially zero. The variable cost is dominated by the emails sent and the regular checks that look for status changes. Bedrock fires only when a forwarded carrier email needs reading and once a month for the summary, so it stays a small sliver. At 3,000 orders a month the bill lands around $14.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with Function URLs for the carrier webhook and the unsubscribe link, EventBridge Scheduler for the regular status check and deferred sends, DynamoDB on-demand, S3 (with versioning), SES inbound + outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) for reading forwarded carrier emails and the monthly summary. No API Gateway, no NAT Gateway, no always-on compute.
Where does the order list live?: In a Google Sheet in a Drive folder. One row per order with order number, customer name, customer email, carrier, tracking number, current status, last-updated date, and a link to the order. A small drive-sync Lambda mirrors the sheet to S3 every few minutes; the notifier reads from S3 to keep Drive API calls predictable and to get S3 versioning for free.
Does the notifier use AI?: Sparingly. The regular check uses no AI — it’s plain Python that reads each order’s tracking status and decides which update to send. Bedrock Haiku 4.5 fires only when somebody forwards a carrier email the webhook missed (it reads the email and proposes a status change for one-tap approval) and once a month for the summary narrative. Most of the system is deterministic by design.
How does an update reach the customer without being annoying?: Each status sends exactly one update — shipped, out for delivery, delivered, delayed. The notifier writes down every send so it never repeats one. Updates respect quiet hours (default 9pm–8am local) so nobody gets a 2am email. A customer can unsubscribe from any update with one tap. And the same order never gets two “shipped” emails even if the carrier reports the same status twice.
What happens when a delivery runs late?: Each order has an expected delivery date. If the order passes that date without a delivered status, the notifier marks it delayed, sends the customer a warning with what it knows, and tells the owner so a human can chase the carrier before the customer has to ask. Every delay is recorded in the sn-audit DynamoDB table with the order, the date, and what was sent, so the trail is auditable later.

All posts

Frequently asked questions

Other series