Docs / Connect your data

GitHub

Get an alert when pushes, pull requests or deploys spike, drop or stop.

In short: make a Webhook URL in the dashboard (Senders (Connect)) and add it to your repository's webhooks. Each push, pull request or deploy counts one.

The steps below work for you or your coding agent. Your agent does every step that needs no secret. The key comes from npx countwatch init (you approve it); a Webhook URL you make under Senders (Connect), or approve for your agent.

Counts a repository's events (pushes here; pull requests or deployment statuses the same way) per 5 minutes and alerts when activity spikes, drops or stops. GitHub calls a Webhook URL: no code runs on your side. Needs admin rights on the repository (the person's), and a CountWatch account (the person signs up at https://countwatch.com/login) and a Webhook URL the person makes in the dashboard (Senders (Connect), https://countwatch.com/dashboard/connections?tab=senders): it is a secret for one metric, so the agent gets it only through MCP webhook_url, after the person approves, to paste into the tool itself.

1. The Webhook URL and the watch

The agent creates the watch as a push watch first (a 5-minute window without hits is zero; a watch's source is fixed by its first count; until then it waits for that count): over MCP, manage {"action": "create_watch", "body": {"metric": "pushes", "tags": {"repo":"<repo>"}, "source": "push", "recipe": "github"}}; with an API key:

curl -sX POST https://countwatch.com/v1/ingest -H "Authorization: Bearer $COUNTWATCH_API_KEY" -H "Content-Type: application/json" \
  -d '{"source":"push","recipe":"github","points":[{"metric":"pushes","tags":{"repo":"<repo>"},"add":0}]}'

The Webhook URL for pushes is a secret for this one metric. The person makes it in the dashboard (Senders (Connect), https://countwatch.com/dashboard/connections?tab=senders) and pastes it into the tool. When the agent sets the webhook up in the tool itself (through the tool's own MCP server or API), it may get the URL instead with MCP webhook_url {"action": "make_webhook_url", "metric": "pushes"}, which the person approves first, and paste it only into that tool: never into code, a repository, chat or logs. API keys and signing secrets stay the person's.

Query parameters on the link become tags (?repo=api is the tag repo:api): the watch here must have the same ones as the link's hits (each combination of tag values is a watch: mind the plan's watch limit).

2. Add the repository webhook

The person adds it (the dashboard's New watch shows the same steps), with ?repo=<repo> at the end of the payload URL:

1. In the repository, go to Settings → Webhooks → Add webhook.
2. Paste the Webhook URL as the payload URL, content type application/json.
3. Choose Just the push event, then press Add webhook.

Or this, with the person's gh login; an agent runs it only when the person's request names this webhook:

gh api repos/<owner>/<repo>/hooks --method POST --input - <<'JSON'
{"name": "web", "active": true, "events": ["push"], "config": {"url": "<webhook url>?repo=<repo>", "content_type": "json"}}
JSON

One metric per event type: make another link (github_pull_requests, events ["pull_request"]) for another type. GitHub sends an X-GitHub-Delivery id, so a redelivery counts once. GitHub's first ping event counts 1.

3. History (optional)

GitHub keeps no full record of past pushes (the events API returns the last 300 events at most), and commits are not pushes (one push carries several), so a commit count would teach the wrong usual level. Skip the import: the watch learns from live data, with starter rules meanwhile.

Check it works

1. Data arrives. check_setup (or curl -s https://countwatch.com/v1/status -H "Authorization: Bearer $COUNTWATCH_API_KEY"): the pushes {repo=<repo>} watch shows last_request_at, and missing_buckets_24h stays 0 (explicit watches). Do what next_actions says.
2. History is in. GET /v1/imports/{import_id} shows status: done and the rules chosen for pushes {repo=<repo>}, with the alerts they would have raised. (Skipped the import? The watch learns from live data; starter rules apply meanwhile.)
3. An alert reaches you. The person turns on e-mail alerts in the dashboard (Destinations (Connect), https://countwatch.com/dashboard/connections?tab=destinations), or you add a webhook (manage create_destination, then verify_destination; the endpoint answers the challenge, see https://countwatch.com/agent). A write key cannot read alerts: read them with MCP alerts, or with GET /v1/alerts and an admin key. Then manage {"action": "send_test_alert"}: every active destination receives a test alert (test: true) within a few minutes. Real alerts go only where the watch's group chose (Alerts go to, or manage update_group with destination_ids); until then they stay in the app.

For agents: this page as Markdown.