/log-watch

name: log-watch
description: "Set up a scheduled agent that reads a small team's existing production logs, flags suspicious activity, and pages a human, without a SIEM or security staff. Use when the user mentions 'log watch,' 'watch my logs,' 'alert me if someone is attacking,' 'no SIEM,' 'poor man's SIEM,' 'agent reads CloudTrail,' 'cron job that checks logs,' 'page me on suspicious logins,' 'Vercel logs alerting,' 'Sentry security alerts,' 'Supabase auth logs,' 'Stripe dispute spike,' 'credential stuffing alert,' 'two-stage classifier,' 'Haiku then Sonnet,' 'log monitoring cost,' or has Vercel / Heroku / Render / Sentry / Postgres / Stripe / Cloudflare / CloudTrail / GitHub logs and wants to know when something bad happens."
allowed-tools: Read, Grep, Glob, Write

Log Watch — Scheduled Agent Log Review and Paging for Teams Without a SIEM

Most small SaaS teams already have the logs that would show an attack: Vercel or Heroku request logs, Sentry errors, a Postgres auth table, Stripe events, CloudTrail. Nobody reads them until after the incident. This skill wires a scheduled agent over those sources: cheap deterministic filters and a small model cut the volume, a stronger model looks only at what got flagged (with the previous run's state), and a human gets paged with a "why this fired" summary and raw event links.

**Detection only.** The watcher reads logs and sends messages. It never blocks an IP, disables a user, rotates a key, or changes config. Response is a human decision, made in `incident-triage`.

`Write` is pre-approved because the main output is a file: the `log-watch.md` plan, plus an optional scaffolded job. Don't write anywhere else without asking.

Cross-references: `siem-detection` for when the team outgrows this and adopts a real SIEM (the detections here port to Sigma); `incident-triage` for what happens after a page is real; `soc-operations` for regulated environments that need a SIEM/MDR and staffed triage instead of this; `prompt-injection` because the watcher is an LLM reading attacker-controlled text; `secrets-audit` for the API-key events this detects and for storing the watcher's own credentials; `cloud-audit` and `iam-audit` for the CloudTrail/IAM side; `threat-hunting` for one-off hunts that later graduate into a detection here.

When this fits, when it doesn't

Fits: 1–30 engineers, PaaS-hosted (Vercel, Heroku, Render, Fly, Supabase, Neon), no SIEM, no on-call security person, some logs already retained somewhere.

Doesn't fit, say so and point elsewhere:

• **Regulated environments** (HIPAA, PCI DSS, SOC 2 with a monitoring control, FedRAMP) that need retained, tamper-evident logs and documented triage. A cron job doesn't satisfy that; use `soc-operations` and a SIEM or MDR. Log-watch can still run as an extra layer.
• **Already have a SIEM.** Write the rules there with `siem-detection`.
• **Endpoint threats** (malware on laptops). Logs from PaaS won't show it; that's EDR territory.

Authorization and safety (before anything else)

1. Confirm the user owns or operates the systems whose logs will be read, and that reading them is within their role. Logs contain customer PII (emails, IPs); the plan must say where log excerpts go (model provider, Slack) and the user must be OK with that. 2. Every credential the watcher holds is **read-only** and scoped to log/event read. The watcher's only writes are to its own state store and the paging channels. 3. Logs are **untrusted input**. See [Logs are untrusted input](#step-6--logs-are-untrusted-input) — design this in from the start, not as a hardening pass.

Workflow

Step 1 — Inventory the sources the team already has

Ask which of these exist, how long each retains data, and how to read it with a read-only credential. Don't propose new log infrastructure until you've used what's there. Then map each source to the detections it can support.

| Source | How to read it (read-only) | Supports detections | Watch out for | |---|---|---|---| | Vercel runtime/request logs | `vercel logs --since … --json`; log drains to a store for anything older than the plan's retention | D4 path probes, D5 webhook sig failures, D6 export volume (if logged), D10 egress (if app logs outbound) | Short retention on lower plans; drains needed for history. `vercel logs --help` for current flags | | Vercel team activity | `vercel activity` | D2 role grants (team), D3 tokens | Team-level, not app-level | | Heroku | `heroku logs -a APP --dyno router`; `heroku drains` to a store | D4 (router lines carry `path=`, `status=`, `fwd=`), D5 | `heroku logs` returns ~1,500 lines max; use a drain for scheduled reads | | Render | Log streams (syslog) to a log provider; dashboard/API | D4, D5 | Read from the destination provider, not Render | | Sentry | Issues/events API with a read-scoped token | D5, auth exceptions, new error classes on auth/admin routes | Sampling can hide bursts; error events are not request logs | | Supabase / Neon / Postgres auth tables | SQL as a read-only role | D1 credential stuffing, D2 role grants, D3 API keys, D6 export volume, D7 impossible travel | Failed logins are often *not* in the table — check what's actually recorded | | Stripe | Events API with a restricted key (Events: read) | D8 refund/dispute spikes, D3 (`api_key` changes are in the Dashboard, not Events) | Events API keeps ~30 days | | Cloudflare | Security Events, GraphQL Analytics API, Logpush (plan-dependent) | D4, D1 (by path), WAF hits | Field availability and retention vary by plan | | AWS CloudTrail | `aws cloudtrail lookup-events` with `cloudtrail:LookupEvents` only | D9 IAM changes, root logins, access-key creation | Management events only, 90 days, ~2 req/s; IAM/sign-in events land in `us-east-1` | | GitHub audit log | `gh api -X GET /orgs/ORG/audit-log` | D2 org/repo role grants, D3 PAT/deploy-key/webhook creation | REST audit-log API needs Enterprise Cloud; other plans: UI/export only | | Egress logs (DNS, proxy, VPC flow, Cloudfla