What is a job status notifier?

A small serverless system for service businesses — repair shops, trades, studios — that keeps a customer in the loop as their job moves through stages on a board or sheet. Each time a job changes stage (“received” to “in progress” to “ready”), the notifier sends the customer one update by SMS or email, written in the shop’s voice, with a photo of the work and an honest ETA for the next stage. A daily sweep chases any job that has sat too long in one stage. It is not a parcel tracker — it follows work happening in a shop, not a box in transit.

How much does it cost to run?

About $2.30/month at typical small-business volume — roughly 200 jobs a month with around five stage changes each. Nothing runs when the board isn’t moving, so the fixed cost is essentially just Secrets Manager. The biggest variable line is SMS: every text is metered per message, so it grows fastest as you push more updates to text rather than email. One small Bedrock Haiku 4.5 call per update writes the wording; that and everything else round to cents.

Which AWS services does it use?

Lambda (Python 3.14, arm64), EventBridge (a custom bus for stage-change events, plus Scheduler for the board poll and the daily sweep), DynamoDB on-demand for the jobs and stage history, S3 for job photos, SES for email and SNS for SMS, SQS with a dead-letter queue, Secrets Manager for the SMS-sender and board credentials, CloudWatch Logs at 7-day retention, AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to compose each message. No API Gateway, no NAT Gateway, no always-on compute. Everything runs in one region, eu-west-2.

How does a stage change trigger a message?

A small watcher polls the job board every few minutes and compares each job’s current stage against the last stage it recorded. When a job has genuinely moved — a known stage, a forward step, not a duplicate — it appends the move to a stage-history table and puts one stage.changed event onto a custom EventBridge bus. A rule routes that event through an SQS queue to the composer, which builds the update and hands it to the sender. The board moving is the only thing that triggers a customer message.

Only to write the words. The stage facts — which stage the job moved to, and the ETA for the next one — come straight from the job record and the shop’s settings, never from a model. Bedrock Haiku 4.5 fires once per update and is handed those real facts with strict instructions to use only them, so it phrases “your repair is now in progress, ready by Thursday” in the shop’s voice without ever deciding what stage the job is in or what the ETA should be.

Can it send a wrong or premature update?

It is built not to. It only sends on a validated forward stage change, never on a sideways edit, a typo, or a duplicate poll. It never invents a stage — if the board says “in progress”, that is what the customer hears, and an ETA is only included when the shop has actually set one. Quiet hours hold any message that would land overnight until morning, and every update is de-duplicated against what was already sent, so a customer never gets the same news twice or a text at 2am.

Series · 7 parts Published June 25, 2026

Job status notifier

A repair shop, a trades crew, a framing studio — they all move every job across the same quiet board: received, diagnosing, in progress, ready. Between each step the customer hears nothing and quietly wonders whether anything is happening at all. This is the design of a small serverless notifier that watches that board and, the moment a job changes stage, sends the customer one honest update in the shop’s own voice — with a photo of the actual work and a real ETA for the next stage. A daily sweep chases any job that has sat too long in one place, so nobody is ever left guessing. It never invents a stage and never sends in the middle of the night. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A job status notifier on AWS for a few dollars a month

The whole system on one page — a job board outside, a stage watcher, a message composer, and a sender inside, plus the daily sweep and the guardrail that it never invents a stage.
02

How a job stage gets updated

How a move on the board becomes a trusted stage change — the poll, the comparison against the last recorded stage, the forward-only and known-stage checks, and the single event that fires.
03

How a customer update gets composed

How one short, honest update gets written — the facts handed in (stage, ETA, photo), the single Bedrock call, the shop’s voice, and why the model can never invent a stage or an ETA.
04

How photos and ETAs get attached

How a photo of the work and a real ETA get attached — the photo dropped at the bench landing in S3 and linked to the job, and the ETA built from per-stage durations with an honest buffer.
05

How a quiet stage gets chased

How a job that has sat too long in one stage gets chased — the daily sweep, the per-stage dwell thresholds, the holding update to the customer and the nudge to the shop, and the quiet-hours and dedupe guards.
06

What the job status notifier costs

A line-by-line monthly cost at about $2.30 for roughly 200 jobs, where the money actually goes, why SMS is the line that moves most, and what the bill looks like at ten times the volume.
07

Engineering reference: the job status notifier architecture

The same system drawn for engineers — Lambda inventory, the EventBridge bus and schedules, DynamoDB tables and keys, the S3 photos bucket, SES and SNS, IAM scope, the Bedrock model id, and the region.

What is a job status notifier?: A small serverless system for service businesses — repair shops, trades, studios — that keeps a customer in the loop as their job moves through stages on a board or sheet. Each time a job changes stage (“received” to “in progress” to “ready”), the notifier sends the customer one update by SMS or email, written in the shop’s voice, with a photo of the work and an honest ETA for the next stage. A daily sweep chases any job that has sat too long in one stage. It is not a parcel tracker — it follows work happening in a shop, not a box in transit.
How much does it cost to run?: About $2.30/month at typical small-business volume — roughly 200 jobs a month with around five stage changes each. Nothing runs when the board isn’t moving, so the fixed cost is essentially just Secrets Manager. The biggest variable line is SMS: every text is metered per message, so it grows fastest as you push more updates to text rather than email. One small Bedrock Haiku 4.5 call per update writes the wording; that and everything else round to cents.
Which AWS services does it use?: Lambda (Python 3.14, arm64), EventBridge (a custom bus for stage-change events, plus Scheduler for the board poll and the daily sweep), DynamoDB on-demand for the jobs and stage history, S3 for job photos, SES for email and SNS for SMS, SQS with a dead-letter queue, Secrets Manager for the SMS-sender and board credentials, CloudWatch Logs at 7-day retention, AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to compose each message. No API Gateway, no NAT Gateway, no always-on compute. Everything runs in one region, eu-west-2.
How does a stage change trigger a message?: A small watcher polls the job board every few minutes and compares each job’s current stage against the last stage it recorded. When a job has genuinely moved — a known stage, a forward step, not a duplicate — it appends the move to a stage-history table and puts one stage.changed event onto a custom EventBridge bus. A rule routes that event through an SQS queue to the composer, which builds the update and hands it to the sender. The board moving is the only thing that triggers a customer message.
Does it use AI?: Only to write the words. The stage facts — which stage the job moved to, and the ETA for the next one — come straight from the job record and the shop’s settings, never from a model. Bedrock Haiku 4.5 fires once per update and is handed those real facts with strict instructions to use only them, so it phrases “your repair is now in progress, ready by Thursday” in the shop’s voice without ever deciding what stage the job is in or what the ETA should be.
Can it send a wrong or premature update?: It is built not to. It only sends on a validated forward stage change, never on a sideways edit, a typo, or a duplicate poll. It never invents a stage — if the board says “in progress”, that is what the customer hears, and an ETA is only included when the shop has actually set one. Quiet hours hold any message that would land overnight until morning, and every update is de-duplicated against what was already sent, so a customer never gets the same news twice or a text at 2am.

All posts

Frequently asked questions

Other series