t3-watch

t3-watch

An agent on call for the things nobody watches. Checks run free; your agent wakes only when something changes.

Watch keeps an eye on the systems you run: CI, cloud accounts, API keys, URLs and scheduled jobs. It sets itself up from the projects and logins already on your machine, and runs its checks as plain code on its own clock, so they spend no model tokens.

• The page is for knowing and deciding: what's broken, what's waiting for you, and one-click Turn on, Pause and Add key. Keys are pasted here, never in chat. Details edits a check's name, how often it runs and its settings, and deletes one; a deleted check keeps its history and can be restored.
• The chat is for understanding and authoring. A "Watch" thread in T3 Code (or any MCP client) investigates failures, writes new checks and shows the page inline.

[The demo in 60 seconds: one command starts it, Home leads with the broken check and the agent's note on it, a check the agent wrote gets turned on, the products open with their checks, and Details shows a key and a signed test alert]

The demo in 60 seconds, recorded from npx @lfg-labs/t3-watch demo with its sample data. Click it for the sharper MP4, which GitHub hands over as a download.

Website · MCP Registry

Try it first

npx @lfg-labs/t3-watch demo

With Node 24 or newer, the demo runs a Watch with sample checks on this machine and prints a sign-in link for its page. Every check and alert in it gets a canned answer, and it neither scans nor takes keys, so it reaches none of your accounts and sends nothing off the machine. Signing in to it leaves your own Watch signed in. Ctrl-C stops it and removes it. The video and the screenshots here come from it.

Install

Watch needs Node 24 or newer, on a machine that stays on.

npm install -g @lfg-labs/t3-watcht3-watch install

install runs Watch in the background at login (systemd on Linux, launchd on macOS), adds its MCP server to Codex and Claude Code, and prints a sign-in link for the page. A sign-in link works once, within 10 minutes, so a copy left in a terminal, a log or a chat is useless after use. For each other browser, t3-watch url prints a new one, or ask your Watch thread for the page. A browser gets its own session, never the access token agents use, and t3-watch signout signs every browser out while agents keep working.

T3 Code can run several accounts for one provider, each in its own home. t3-watch install --all also adds Watch's MCP server to every enabled Claude Code and Codex home in T3's settings, so a Watch thread works on any account, and t3-watch uninstall --all takes it out of them again.

To run from a checkout instead, clone this repository, run pnpm install && pnpm build, then node bin/t3-watch.js install.

On Linux, loginctl enable-linger $USER keeps it running while you're logged out.

If Tailscale runs on the machine, install serves the page on your tailnet over HTTPS with tailscale serve, never funnel, on port 8461 or the next free one, and sign-in links point there. It opens on your own devices and nowhere else. Tailscale lets only its operator do this: if install says so, run sudo tailscale set --operator=$USER once and install again. --no-tailscale keeps the page on this machine, a publicUrl you set in ~/.t3-watch/config.json is left as it is, and uninstall stops the route install made. If host there is a tailnet address, Watch listens on 127.0.0.1 as well, so tailscale serve can front it.

First run

Open the page. It first shows what Watch may read: the folders it would look in, ~/Projects and any of ~/code, ~/src and ~/dev that exist, each with how many git repositories it holds, and three logins: the GitHub CLI, AWS CLI profiles, and vendor keys in .env files. Untick what Watch should leave alone, add a folder if you like, and press Scan these. Watch reads only what is ticked: it finds the vendors your code uses, tests the logins you allowed, and runs every suggested check once. Untick the checks you don't want and press Watch these. Add services shows the same choice before each later scan, and an agent can read it with watch_sources.

Watch only reads. Keys it finds are stored encrypted in ~/.t3-watch, and their values never reach the page, a log or an agent.

The Watch thread

install adds a project named Watch to T3 Code, in a folder of its own with no code, so a thread there starts without any repository's hooks, skills or memory. Start a thread in it and say "Show me Watch". The agent calls watch_home. On Codex threads the page appears inline and its buttons work; on other providers you get the same state as text. install --no-project skips the project, and uninstall leaves it with its threads.

Things to ask:

• "What's broken?" or "Why did CI fail on api?"
• "Pause the Stripe checks until Monday."
• "Make sure the nightly import ran." The agent drafts a check, runs it once, and leaves it for you to turn on.
• "Watch Missive too." The agent writes a vendor description and tests it with your key.
• "Put shop.example under Storefront." Home groups checks by product, guessed from names; when a site's repository has another name, the agent names the product, and the repository follows.
• "Set up alerts." Alerts in the page's Details walks you through three steps. Press Make a signing secret, which the page shows once. Say "Set up alerts" here: the agent creates a T3 webhook task bound to the thread that checks Watch's signature, asks you to paste the secret into a private T3 card, gives Watch the task's address, and sends a test alert. The task accepts it only when it holds Watch's secret. Send a test alert on the page, or t3-watch alerts test in a terminal, sends another whenever you want to check, and t3-watch alerts says how the last one went. The secret never passes through the chat, Watch refuses one sent over MCP, and only the webhook's host shows on the page. From then on, a check that starts failing, recovers or can't run wakes the thread, and the agent looks into it before you open it. Checks that keep passing send nothing. A check that was passing counts as failing only when two runs in a row do not pass; Watch runs it again within a minute of the first, so one dropped request wakes nobody. A recovery counts at once.

Slack alerts

In Details, Alerts, paste your own Slack incoming-webhook URL into the password field and press Save Slack webhook. Watch encrypts it with the same installation key as vendor keys, never shows it again, and never hands it to an agent. Send Slack test checks that the channel accepts messages. Replace the URL there, or Disconnect Slack to stop sending. The demo takes no real Slack URL.

Create an incoming webhook in your Slack app and choose its channel. Slack and GovSlack are supported. Slack needs no T3 Code account, and T3 thread alerts keep working alongside it. Each destination has its own delivery queue. New or replaced destinations start with future changes, not old events.

Watch sends one Slack change at a time, at least a second apart. Failed sends retry on the service's minute timer, honor Slack's Retry-After on HTTP 429, and stop after twenty attempts. Details shows the latest test and delivery result. A Slack notification reports the change; automatic investigation still needs the T3 thread webhook.

When Watch's own connection drops

When a check that needs the internet stops passing, Watch first asks whether it can reach the internet at all. If neither https://www.gstatic.com/generate_204 nor https://one.one.one.one/cdn-cgi/trace answers within 5 seconds, it holds the result: the run shows in the check's history as held, the check keeps its last result, and nothing alerts. Home and the Watch thread's status say when Watch lost its connection. Heartbeats and checks on this machine are never held, and a check's failures are held for at most an hour of its runs in a row, in case the probe addresses are what is blocked.

A slow link gets the same care. When a web or vendor check's connection to a public site times out, drops or cannot finish its name lookup, Watch times its probe. One that takes a second or more, or 400 ms or more while two or more sites newly fail that way within two minutes, means Watch's own link is slow, and the failure is held like an offline one. A refused connection, a bad certificate, an HTTP answer, GitHub and AWS checks, and checks on your own network, by address or by a name such as nas or fritz.box, still count. A check's next run after a held one waits 45 seconds for an answer instead of 15. Home and the Watch thread's status say when the connection turned slow; the spell ends when a probe or a request answers within 400 ms, or a probe no longer shows it slow.

If your network blocks those two addresses, list ones it allows as probeUrls in ~/.t3-watch/config.json and restart Watch. An empty list turns holding off. Watch notices a blocked list on its own: when the addresses fail twice in an hour right after a check reached the internet, it stops holding and says so on Home until one of them answers or Watch restarts. A web request that had just taken longer than the probes wait is the exception: then the link is slow, not the list blocked.

Vendors

Each vendor is a JSON file in catalog/: how to spot it in a project, which variable holds its key, how to send the key, which read-only call proves the key works, and which checks to offer. Adding a vendor is a file, not a release. Watch only sends GET requests to the API origin a description names.

Shipped: Stripe, Pipedrive, Missive, Asana, Airtable, Jotform, Calendly, Vimeo, Sentry, OpenAI, Anthropic, Vercel, Cloudflare, Neon, Supabase, Render, SendGrid, Resend, GitLab.com and DigitalOcean. These new descriptions verify API access, not deployment health or email delivery. Endpoints, required permissions and limits explain which key to use, including Resend's full-access requirement and why Twilio and Linear are not supported yet. Xero is recognised, but sign-in vendors aren't supported yet.

Check kinds that need no vendor file: http, github (through gh; for a scheduled workflow, name it in workflow and add maxAgeSeconds, so a schedule GitHub skipped or disabled fails instead of staying green), aws_metric (through the AWS CLI) and heartbeat (a job pings a URL; add ?status=fail when it fails).

GitHub's runs API sometimes answers, for a while, with no runs at all for a repository that has them. A GitHub check that has listed runs for its repository, branch and workflow holds such an empty list as Watch holds a failure while it is offline: for up to an hour of its runs, and without a probe, since GitHub answered. If the list stays empty past that, the check says so, as in "GitHub listed no runs for main in owner/repo, though it had them before", or "for refresh.yml on owner/repo" when it reads one workflow on any branch. "No finished runs yet" stays for a list with nothing finished in it, and an edit to another branch or workflow starts the check's memory over.

Development

pnpm dev          # the service from source, on 127.0.0.1:8460pnpm test         # unit and integration testspnpm typecheckpnpm build        # server, page and the inline viewnode scripts/record-demo.ts   # the README's demo video again, with Chrome and ffmpeg

Design and requirements live in openspec/.

License

Free and open source under the MIT license.