Database Metrics Digest Agent

Most teams have five numbers somebody checks by hand every morning and a dashboard nobody trusts. You hand this agent those five queries, and at 08:30 it runs exactly those, posts the results to Slack with day over day movement, and names any query that failed instead of leaving a hole. It is deliberately narrow: a fixed query list and read access only, so it cannot drift into writing to your database or inventing a metric no result contained.

What people use it for

• Replace the morning dashboard check - The five numbers land in Slack before anyone opens a laptop, in the same order every day. Nobody logs into a BI tool to answer how yesterday went.
• Catch an overnight drop - A metric that halved during the night shows up in WATCH with both numbers next to each other. You find out at 08:30 rather than when a customer asks on Thursday.
• Give non engineers real numbers - Founders, support and finance read the same digest without needing SQL access or a seat in a reporting tool. The query names you choose become the vocabulary everyone uses.
• Keep a read only path to prod - A fixed list of SELECTs, no ad hoc SQL, and no write operations at all. It is a narrower door into the database than handing another person a psql login.

Before you fork

What do I need to set up first?

A Postgres credential and one Slack channel. Point it at a read only role or a replica, not your primary superuser, and paste your SELECT statements into the query list variable with the name each metric should carry. Anything requiring a VPN or IP allowlist needs the connection reachable from outside your network.

Can it touch or damage my data?

It is instructed to run only the queries you listed and to write nothing at all, and the tools it holds are a select query plus two schema description tools. An entry in your list that is not a plain SELECT is refused and reported rather than executed. Connecting with a read only role makes that a database level guarantee rather than an instruction.

What does it cost to run?

One run per morning, around 30 a month, no matter how large your tables are. Each run is your queries plus one Slack message, so heavy queries cost your database time rather than run count. Keep the list to metrics that return in a few seconds, and the digest arrives before anyone is waiting for it.