Docs / Connect your data

n8n

Count a workflow's runs or items, and get an alert when they spike, drop or stop.

In short: add one HTTP Request node to your workflow that calls your Webhook URL. Each run, or each item, 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 what an n8n workflow does (leads created, forms submitted, rows synced) per 5 minutes and alerts when it spikes, drops or stops. Name the metric for what the workflow does (leads_created, rows_synced), not after n8n. One HTTP Request node at the end of the workflow calls a Webhook URL. Needs 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": "leads_created", "source": "push", "recipe": "n8n"}}; 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":"n8n","points":[{"metric":"leads_created","add":0}]}'

The Webhook URL for leads_created 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": "leads_created"}, 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 node

Copy this node, paste it into the workflow canvas (Ctrl+V or Cmd+V), put the Webhook URL in its URL, and connect it after the step whose outcome you count (so a failed run counts nothing):

{
  "nodes": [
    {
      "parameters": {
        "method": "POST",
        "url": "<webhook url>",
        "sendQuery": true,
        "queryParameters": {
          "parameters": [
            {
              "name": "n",
              "value": "={{ $input.all().length }}"
            }
          ]
        },
        "options": {}
      },
      "name": "CountWatch ping",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.2,
      "position": [
        0,
        0
      ],
      "executeOnce": true,
      "retryOnFail": true,
      "maxTries": 3,
      "waitBetweenTries": 2000,
      "onError": "continueRegularOutput"
    }
  ],
  "connections": {}
}

Or add it by hand, as the dashboard's New watch says (each item that reaches it then adds 1):

1. Add an HTTP Request node after the step you count.
2. Method POST, URL: the Webhook URL.
3. Save the workflow and run it once.

The node above runs once per execution (Settings → Execute Once) and sends n = the number of items that reached it, so one run with 40 new leads adds 40 in one request. It retries a failed call twice, then lets the workflow go on (Settings → On Error: continue): a refused call never fails your workflow, and the missing count shows as a drop. A run with no items does not run the node: the 5-minute window reads as zero, which is what a push watch expects. To count runs instead of items, remove the n query parameter. Every call is one request against the plan, so keep Execute Once on.

Do not add n8n's execution id as ?id=: it restarts from 1 when n8n's database is reset, and the Webhook URL would drop new runs as retries for 4 days.

3. History

n8n keeps its execution history for a short time only. 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 leads_created 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 leads_created, 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.