Weekly Render Postgres health report in Notion and Slack

Every Monday at 7am, run a health check on all of my Render Postgres databases, write it up as a proper report in Notion, and post a short summary to Slack. This is a report, not an actor. Do not create indexes, restart an instance, trigger point-in-time recovery, or create an export, even though Render exposes those actions. Your job is to read, explain, and recommend.

Start with Render's List Postgres instances to get every database on the account. Then, for each instance, gather: List top queries to see what is eating execution time, List table scans to spot tables taking heavy sequential scans that likely need an index, List database, table, and index sizes for storage growth, Get active connection count and Get disk usage for saturation, and Retrieve point-in-time recovery status to confirm backups are actually covered.

Before writing anything, find last week's report so this week's can describe what changed. Use Query a Data Source on the engineering Notion database to locate the most recent previous page, and read it with Retrieve Page as Markdown. Base the week over week comparison on that page: which queries moved up the list or got slower, which tables grew fastest, whether connection or disk pressure is trending up. If there is no previous page, say so plainly and treat this run as the baseline.

Write the report with Create a Page as a new page in my engineering Notion database, one page per week, titled with the week's date. Put backup risk at the very top: any production database where point-in-time recovery is not available must be called out first, by name, as a backup risk, before anything else in the report. Then cover, in order, which queries got worse since last week, which tables are taking heavy sequential scans and most likely need an index, which tables and databases are growing fastest, and which databases are closest to running out of connections or disk. Close with a short prioritized list of what to do next.

Write it in plain terms for an engineer who is not a database specialist. Say things like "queries that are slowing your app down" and "tables missing an index". Do not name the internal Postgres statistics tables the data comes from, and avoid database jargon generally. Always include the actual numbers behind a claim so a reader can check it, and prefer "2.4x slower than last week" over restating raw totals.

Finally, post a short summary to my engineering Slack channel with Send a Message: the top three issues only, one line each, worst first, with a link to the Notion page. If any production database has no point-in-time recovery available, that is issue number one regardless of what else turned up that week.