PlanetScale Database On-Call Analyst
An on-call analyst for your PlanetScale databases. It receives PlanetScale's native alert events over a webhook, enriches each one with query insights, correlates it against recent deploy requests and its own learned baseline, then posts a triaged incident to Slack - or stays silent when the alert is already known.
At 02:14 PlanetScale notices something wrong and says so. Instead of a raw payload dumped into a channel, Slack gets a short note: the query whose reads jumped 40x overnight, the tables it touches, the schema change that shipped 40 minutes earlier and probably caused it, and a view on how bad it is. Or - more often - Slack gets nothing at all, because the agent recognises this one from last Tuesday and quietly writes down that it happened again.
PlanetScale already raises the alarm. Nobody is listening. That is the gap this fills. PlanetScale watches for slowdowns, memory exhaustion, storage filling up, deploys that failed or got rolled back, and staff asking for access - it even works out its own advice on making a slow query faster
- then sends each one to whatever address you nominate. These are real incidents, not a stream of metrics: a typical database raises a handful a day, and the noisiest kind is throttled before it ever reaches you. They are rare, they matter, and they almost always arrive somewhere nobody is looking.
Being told wakes it up; asking is how it learns anything. The alert is only a nudge. It carries the fact that something happened, not the detail - so the agent turns around and asks PlanetScale for the rest: what the slowdown actually was, which queries were running at the time and how much each one was reading to return how little, and whether the worst offender has always behaved this way. It pulls that detail on demand, for one incident at a time, which is why it never drowns.
The baseline is what makes it an analyst rather than a formatter. Every
"AI for alerts" demo reformats a threshold breach. This one remembers.
memories/baseline/ holds what normal looks like for each database - the
queries it has seen, what they usually cost, and which problems someone has
already acknowledged. memories/incidents/ is a running record of every
alert that arrived and what was decided about it. So it can answer the three
questions an on-call engineer actually asks: what exactly happened, is this
new, and what changed just beforehand. The last one it answers by looking at
what shipped in the hours around the incident.
Silence is a feature. A known problem behaving in its usual way gets written down and nothing more. Storage crossing an early mark is noted; a late one wakes someone. The agent is told plainly that saying nothing is a valid and usually correct outcome - which is the whole answer to alert fatigue, and the reason the channel stays worth reading.
It sets up its own plumbing. On first run it looks at what alerting is already configured, signs itself up for what it wants, and sends a test through to prove the path works end to end. One token in, no dashboard clicking.
One Slack connection, both directions. The alerts come in through the trigger; Slack is everything else. When something is worth raising it goes out through the same Slack connection the team already talks to, and it arrives as a conversation rather than a one-way announcement - so the engineer who answers at 02:14 is talking to the analyst, and can ask "why do you think it was that deploy?" without leaving the thread. That same connection is the front door for "what's been going on with the orders table this week?", answered from the baseline the alerts built. There is no second Slack credential anywhere in this blueprint.
Swap points: escalate to a different channel by telling the agent, or swap Slack for somewhere else entirely - the baseline stays the source of truth. Widen or narrow which alerts it signs up for. Adjust the escalation rules in the backstory if your team wants more or less noise, and add databases by telling the agent about them - the roster is just onboarding.
A note on trust. PlanetScale can only send alerts to a plain address; it cannot be handed a password to prove the alert really came from it. So the receiver is open, and its unguessable address is what protects it - the same arrangement as a Slack incoming webhook. Treat that address as a secret, because anyone holding it can feed the agent a made-up alert. Two things keep that from mattering much: the agent checks every claim against PlanetScale before acting on it, and it only ever reads, so the worst case is a misleading message rather than a change to your database. PlanetScale does sign what it sends, but checking that signature is not something the receiver can do yet.
Backstory
Common information about the bot's experience, skills and personality. For more information, see the Backstory documentation.
Skillset
This example uses a dedicated Skillset. Skillsets are collections of abilities that can be used to create a bot with a specific set of functions and features it can perform.
Install Baseline Storage Tools
Installs list, read, write, delete, move, copy, and search tools for the Database Baseline space. Install these first - every baseline read and every incident log entry goes through them.Install PlanetScale Insights Tools
Installs read-only PlanetScale tools - anomalies, query insights, query errors, branches, and deploy requests. Use these to work out what an alert actually means and what shipped before it.Install PlanetScale Webhook Tools
Installs PlanetScale webhook management tools - list, create, delete, and test. Use these during onboarding to register your own receiver URL, and never to point a webhook anywhere else.Start Slack Conversation
Escalate an incident by opening a conversation in Slack. A webhook-driven run has no thread to reply into, so use this to raise the incident in the escalation channel recorded in your baseline index. It goes out through your own Slack integration, and the engineer can reply in-thread and keep talking to you.
Secrets
This example uses Secrets to store sensitive information such as API keys, passwords, and other credentials.
PlanetScale Service Token
The service token for the PlanetScale API. Enter it as `TOKEN_ID:TOKEN` - PlanetScale uses a bare `Authorization: <TOKEN_ID>:<TOKEN>` header rather than a Bearer scheme.
Terraform Code
This blueprint can be deployed using Terraform, enabling infrastructure-as-code management of your ChatBotKit resources. Use the code below to recreate this example in your own environment.
A dedicated team of experts is available to help you create your perfect chatbot. Reach out via or chat for more information.
