Weekday DynamoDB health check in Slack

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.