Back to Blog

Weekly Database Reports with Claude Cowork (Scheduled Tasks + Live Data)

Use Claude Cowork scheduled tasks with a read-only database connector so Monday's KPI summary runs on live rows — no weekly CSV export. Prompts, /schedule setup, and safety checklist.

Claude Cowork can run the same task every week on a schedule. If that task can also query your database, Monday morning stops being “export CSV → upload → re-explain the question.”

You write the report prompt once. You connect a read-only MCP endpoint once. You /schedule it weekly. You open a draft built on current rows.

This guide is for founders and ops people living in Claude — not a Connect-click tutorial. If you want the developer/Claude Code version of the same habit, see weekly database reports with Claude Code. Plain-English ad-hoc questions: ask Claude about your database.

What each piece does

| Piece | Job | |--------|-----| | Your database | Holds signups, orders, cancellations | | MCP gateway (e.g. Synra) | One URL, credentials vaulted, read-only SQL, query log | | Claude Cowork | Runs the prompt on a cadence, writes the summary |

Synra does not email you every Monday. Cowork decides when to ask. The gateway answers how the SQL reaches your DB safely.

Why schedule beats “I’ll remember to ask”

Recurring business questions are boring on purpose:

  • New signups this week vs last week
  • Conversions / trials that flipped
  • Cancellations and a short “what moved” note

Doing that by hand means a stale spreadsheet and a lost thread. A scheduled Cowork task with a live connector means the same definition every week, on numbers that aren’t from last Thursday’s export. For why snapshots fail when you’re planning, the same idea shows up in founder workflows — live beats paste.

Keep governed board metrics in Metabase or Looker. Use Cowork for a short narrative plus a few checks you keep Slack-ing eng for. See AI chat vs BI dashboards.

Before you schedule

  1. Staging or replica — not casual production primary (staging first)
  2. SELECT-only DB user + gateway read-only (why read-only matters, SELECT-only Postgres user)
  3. Table allowlist — aggregates and product tables yes; full identity dumps no (don’t give AI every table)
  4. Run once manually and verify against SQL you trust
  5. Name the connection clearly (staging-weekly-reports)
  6. After the first two automated runs, glance at Usage / audit log

Wire the connector in Claude (Connectors) using your usual Postgres / MySQL / SQL Server setup guide if you don’t have an endpoint yet. Then come back here for the schedule.

Prompt: Monday KPI report

Paste into a Cowork task (adjust after Claude describes your real tables):

You have read-only database access via MCP.
Before any execute_sql: list_tables / describe_table — do not invent columns.

Produce a short weekly report for the previous calendar week:
1. New signups vs prior week (define signup from real tables)
2. Conversions or trial→paid if the schema supports it; else say so
3. Cancellations / churn events vs prior week if those tables exist
4. Call out any metric roughly 2× (or half) the prior week

Rules:
- SELECT only
- Show the SQL you ran
- Under ~400 words (Slack-sized)
- End with a CSV-ready markdown table of cancellation rows (id, date, plan) if available — max 50 rows
- If the connection fails, say so clearly — never invent numbers

First run in an interactive Cowork session. Fix table names. Then schedule.

Turn it into a scheduled task

In Cowork, use /schedule (or Scheduled in the sidebar) and set cadence to weekly (e.g. Monday morning in your timezone).

Instruction to Claude when creating the schedule:

Schedule this Monday KPI report weekly.
Reuse the same metric definitions after the first successful run.
If MCP/database tools fail, output a clear error — do not fabricate KPIs.

Exact UI labels move; the habit doesn’t: stable prompt + live connector + weekly cadence.

Good weekly jobs vs bad ones

Good: counts you already understand; short anomaly notes; Slack-sized markdown; a small CSV-ready table for Excel.

Bad: inventing LTV with no columns; scanning full users PII every Monday; heavy analytics on the production primary; treating Cowork as a write-back “data cleaner.”

If columns keep getting guessed wrong, force describe-first — stop AI guessing column names. If tables live outside public, see Postgres schemas beyond public.

When the report looks wrong

  • Way off — wrong connection or wrong “signup” table; check Usage for which credential ran
  • Weird status filters — SELECT DISTINCT status and lock the definition in the prompt (metric traps)
  • Spike in cancellations — don’t stop at the count; dig in with ask AI why customers cancelled

Recurring reports are often why a non-engineer connects a database at all. Safe read-only endpoint, one verified prompt, /schedule weekly — then show up to a draft instead of a blank export ritual.

Read-only gateway: mcpserver.design. Claude Cowork owns the calendar.

Related reading:

← Back to Blog