loggie
Start free

Cloudflare · Workflow guide

Cloudflare Tunnel health checks for AI agents

Have your AI agent compare Cloudflare Tunnel status with your expected inventory through Loggie and hand operators a triage list, with read-only access.

Who this is for: Infrastructure operators managing several Cloudflare Tunnels who want a useful triage queue rather than another raw status dump.

Before you start

  • A Cloudflare connection in Loggie with a provider token scoped to the intended account and tunnel-read permissions.
  • An agent with read access to tunnel status and relevant connection details. Keep DNS, Access, and tunnel modifications outside this workflow.
  • An expected tunnel inventory with operator-approved names, owners, maintenance windows, and intended availability.

In your Loggie workspace, connect Cloudflare, create an agent identity, and review its access. On the agent’s machine, use Node.js 20 or later and initialize the CLI:

npm install -g @loggie-ai/cli
loggie init
loggie discover

Enter the agent’s Loggie key through the initialization prompt. Keep provider credentials in the connection setup, not in the agent prompt. Use the connection slug returned by discovery in the examples below.

Step-by-step workflow

  1. Compare reality with an expected inventory

    An inactive tunnel is not necessarily an incident. It may belong to a retired service, a development machine, or planned maintenance. Start with a small inventory of tunnels that are expected to be connected during the reporting window.

    Assign an owner and an approved diagnostic checklist to each service. Keep credentials, private hostnames, and sensitive network detail out of any broad report. The agent needs enough context to route the issue, not a copy of the infrastructure secrets.

  2. Read current tunnel status through Loggie

    Connect the correct Cloudflare account and initialize the agent’s Loggie CLI. Discover the connection slug and inspect the list endpoint. Replace cloudflare and ACCOUNT_ID with the values for your workspace.

    The starter call excludes deleted tunnels. Follow the pagination described by the endpoint and record the fetch time. Verify response-level success and errors as well as HTTP status before interpreting an empty result as an empty inventory.

    loggie discover cloudflare --endpoint '/accounts/{account_id}/cfd_tunnel' --method GET
loggie call cloudflare GET /accounts/ACCOUNT_ID/cfd_tunnel --query 'is_deleted=false&per_page=100' --pretty

  3. Distinguish a status exception from a service outage

    Match returned tunnel IDs with the expected inventory. For unexpected states, read the individual tunnel and available connection details. Report whether the observation is new, repeated, or occurring during a maintenance window.

    Pair tunnel status with an approved external health check, and give the operator the next diagnostic step from the inventory checklist.

  4. Route the brief without changing infrastructure

    For each exception, give the expected state, observed state, timestamp, owner from the inventory, and next check. If there is no new exception, avoid sending the same alert again. Your agent runtime can save prior state and handle notification routing.

    Keep tunnel restarts, connector-token changes, DNS edits, and Access policy updates behind a separate reviewed action. This workflow narrows the investigation; it does not need permission to change production connectivity.

Cloudflare agent prompt

Adapt this prompt to your connected account and the scope you have approved.

Compare current Cloudflare tunnel status with the approved expected inventory. Exclude retired tunnels and honor maintenance windows. Return new or changed exceptions with tunnel ID, timestamp, expected and observed state, inventory owner, and next diagnostic check. State whether application health was independently checked. Do not restart connectors or edit DNS, tokens, or Access policies.

Example Cloudflare report

Example output with invented data.

Tunnel check: 12 expected, 11 healthy

New exception
  build-runner-02 (owner: platform team)
  Expected healthy, observed down since 06:42 UTC
  Next: check the cloudflared service on the host, then host reachability
  App health: not independently checked
Suppressed
  staging-db-proxy: inactive, inside its maintenance window until 08:00 UTC

No infrastructure changes made.

Success checks

  • Compare the returned inventory and status with the Cloudflare dashboard for the same account.
  • Test an expected inactive tunnel and a maintenance-window exception so they do not become false incidents.
  • Verify the agent lacks mutation access and that a repeated unchanged condition does not create duplicate alerts.

Pitfalls

  • Tunnel status is one signal, not an end-to-end uptime test. A connected tunnel can front an unhealthy app, and a down tunnel does not say whether power, network, credentials, or the connector failed.
  • A missing tunnel may indicate account scope or pagination problems rather than deletion.
  • Use stable tunnel IDs to track changes; display names can be renamed.

Sources