Weekday DynamoDB health check in Slack

A quiet morning audit that flags missing backups, stale snapshots, and unusual table growth — and only pings you when something actually needs a look.

Agentic Task
Amazon DynamoDBSlackEngineeringOperationsNotifications & AlertsDaily Digests
PromptCreate

Every weekday at 8:30am, run a health audit across all of my DynamoDB tables and post a compact summary to Slack whenever something needs my attention.

Step 1 — enumerate. Call Amazon DynamoDB List Tables to get every table in the account and Region, paging through LastEvaluatedTableName until the last page. For each table, call List Tags Of Resource; skip the table entirely if any tag value equals scratch or ephemeral (case-insensitive).

Step 2 — inspect each remaining table. For every non-skipped table, call Describe Table (capture status, key schema, item count, size in bytes, and provisioned capacity if any), Describe Continuous Backups (capture point-in-time-recovery status), and List Backups scoped to that table (capture the most recent on-demand backup timestamp, or none if there is no on-demand backup).

Step 3 — compare against last week. There is a dedicated history table called dynamodb_health_history with a partition key TableName (S) and sort key SnapshotDate (S, ISO date). For each audited table, call Get Item with today's date minus 7 days as the sort key to fetch last week's baseline row (item count and size). If the row exists, compute week-over-week growth as a percentage; treat anything above 25% growth in item count or size as unusual (this threshold is a knob).

Step 4 — write today's snapshot. For each audited table, call Put Item into dynamodb_health_history with TableName, SnapshotDate (today, ISO), ItemCount (N), SizeBytes (N), PitrEnabled (BOOL), and LastOnDemandBackupAt (S, ISO, or absent if none). This is what tomorrow and next week compare against.

Step 5 — classify findings. For each table, decide one of three states. Action needed: point-in-time recovery is disabled, OR there is no on-demand backup within the last 30 days, OR week-over-week size or item count grew by more than the growth threshold. Attention: table status is anything other than ACTIVE, or the table is new (no baseline row from a week ago yet), or growth is between 10% and 25%. Green: none of the above.

Step 6 — post to Slack. If every audited table is green, do not send a message — stay silent on quiet weeks. Otherwise, use Slack Send a Message to post a compact summary to the configured channel with three sections in this order: Action needed (bulleted list of table names with a plain-English reason each — for example 'your backups are turned off' or 'no recent snapshot in 42 days' or 'grew 38% this week'), Attention (same shape), and Green (a single count like 'X tables healthy'). Keep it short — one line per table, no ARNs, no raw API terms. Prefer everyday language over API jargon: say 'your backups' instead of 'PITR', 'recent snapshot' instead of 'on-demand backup ARN'.

Rules and nuance. Never touch or read the contents of the audited tables — only metadata and backup information. Never send a Slack message when the result is fully green. Skip any table whose status is DELETING or CREATING with a short note in Attention. If List Backups returns a paginated response, keep paging until you find the most recent one — do not stop at the first page. Numbers on the wire are always strings in DynamoDB, so cast item counts and sizes back to numbers before doing the growth math.

What does this prompt do?

  • Every weekday morning, sweeps every DynamoDB table in your account and inspects its schema, size, item count, and backup posture.
  • Flags any table without point-in-time recovery turned on, any table whose most recent on-demand backup is older than 30 days, and any table growing faster than usual week over week.
  • Posts a compact green / attention / action needed summary to your Slack channel so the whole team sees the same picture.
  • Stays silent on quiet weeks — if everything is healthy, no message goes out — and skips any table you have tagged as scratch or ephemeral.

What do I need to use this?

  • An AWS account with DynamoDB tables and an access key that can read table metadata and backups
  • A Slack workspace and the channel you want the summary posted into
  • A dedicated DynamoDB table the workflow can write a daily snapshot row into (so it has a baseline to compare growth against)
  • Optional: tag any table you want the audit to ignore as scratch or ephemeral

How can I customize it?

  • Change when it runs — the default is every weekday at 8:30am, but any cron time works
  • Point it at a different Slack channel, or send to a DM instead
  • Adjust the growth threshold that counts as 'unusual' or the number of days that count as a stale backup
  • Change which tag values mark a table as out of scope, or drop the tag filter entirely

FAQs

Will this touch or change any of my table data?
No. The audit only reads metadata — schemas, sizes, and backup information — and writes a small daily snapshot row into a dedicated history table you point it at. It never reads or modifies the contents of your real tables.
What happens on a week where everything is healthy?
Nothing. The workflow only posts to Slack when there is at least one finding worth surfacing. Clean weeks stay silent so it never becomes background noise.
Does it work with both on-demand and provisioned tables?
Yes. It reads whichever capacity mode each table uses and includes provisioned capacity in the summary when it applies. The growth check runs on every table regardless of mode.
How do I tell it to ignore a specific table?
Add an AWS tag to that table with a value of scratch or ephemeral. The workflow reads tags on each table and skips anything marked that way. You can change the tag values in the prompt if you use different conventions.
How does the growth check work — does it compare against yesterday?
It compares against roughly one week earlier. Every morning it writes a small snapshot of every table's size and item count into a history table, and each run reads the row from about seven days ago as the baseline. That means the first week is a warm-up period.

Related templates

Call overdue Xero customers with an AI collections agent

Every weekday at 10am, an AI voice agent phones your most overdue Xero accounts, logs what each customer promised, and reports back to finance in Slack.

LiveKit
Xero
Deepgram
+2
Agentic Task
Win back LiveChat visitors whose chats went unanswered

Every couple of hours we find the chats your team never answered, email those visitors a real reply, and hand the sensitive ones to a support lead.

LiveChat
Gmail
Slack
Agentic Task
Chat quality review board for LiveChat support leads

Score last week's finished live chats against one rubric, let an AI grader draft the notes with quotes, and send coaching straight to the agent.

LiveChat
Slack
General Input Database
App
Win back no-show and cancelled appointments every morning

Every weekday morning, every appointment that fell through yesterday gets a personal text or email inviting them to rebook, plus a task for the right rep.

LeadConnector
Google Sheets
Slack
Agentic Task
Live Loop returns analytics with product-level drill-down

Pick any date range up to 120 days and see return volume, refund versus exchange mix, and the products behind every number, recalculated each time you open it.

Loop Returns
Google Sheets
Slack
App
Newsletter pre-flight and approval board for Mailjet sends

Every newsletter gets read, checked and signed off in one place, so nothing goes out with a broken link or a half-filled greeting.

Mailjet
Slack
General Input Database
App

Stop finding out about missing DynamoDB backups the hard way.

Get a quiet morning check that only speaks up when a table actually needs your attention.