Control Client Fleet Onboarding (Onboarding)

Control Client Fleet Onboarding (Onboarding)

1. 01

   Create the Control workspace and generate a dbhealth agent key from the Keys page

   Store the public half of the key in Control and keep the private half with the agent install. One key per client environment keeps revocation clean if a retainer ends.

2. 02

   Install the read-only DSN dbhealth agent beside each Postgres database in the client's fleet

   The agent sends a signed report every minute over outbound HTTPS and never transmits rows or query text, which is the line to quote in the client's security review.

3. 03

   Confirm signed reports are arriving once per minute for every endpoint

   A database that has never reported shows as unreachable rather than down; resolve that distinction before the client sees the status list.

4. 04

   Label each database with its client tag (for example client:acme) and set the watched tables that matter for freshness

   Watched tables drive the data freshness signal, so pick the tables whose staleness would actually break a client deliverable, not every table in the schema.

5. 05

   Wire the consolidated Slack channel for down and recovery alerts

   Route all client databases into one channel at onboarding so the agency sees fleet-wide state; split into per-client channels only when a client contract requires it.

6. 06

   Define an initial SLO with an error budget on the client's cluster

   The status list reflects operational intent only once an SLO exists; without one, near limit has no agreed meaning for the client.

7. 07

   Walk the client through the four statuses (serving, near limit, down, unreachable) and hand over the Slack channel

   Set expectations that Control shows one status per database rather than charts, so nobody asks for a metrics dashboard in week two.