Checkpoint Docs

How tunnels work

When you start a tunnel with the CLI, Checkpoint:

Starts a local HTTP proxy that injects the Checkpoint feedback script into every HTML page
Launches a tunnel provider (cloudflared or ngrok) pointed at that proxy
Creates a shareable link with a unique ID
Returns a app.checkpoint.build/share/share_id URL you can send to reviewers

Tunnel statuses

Status	Meaning
Active	CLI is running and sending heartbeats every 30 seconds
Inactive	CLI was stopped cleanly (Ctrl+C / SIGTERM)
Expired	Tunnel was abandoned without a clean shutdown

Share IDs

Every tunnel gets a randomly generated 8-character share ID (e.g. ab3x7qmn) using a lowercase alphanumeric alphabet that avoids visually ambiguous characters. This ID is stable across reconnects.

Reconnecting

If a tunnel with the same name already exists, the CLI reuses it — updating the connection details — rather than creating a new tunnel. This preserves the share URL and all comments.

The injection proxy

Before the tunnel provider is launched, the CLI starts a local proxy that manages communication between the tunnel and your dev server.

Non-HTML responses (JS, CSS, images, API calls) are passed through unchanged
HTML responses have the Checkpoint feedback script injected into head before being returned to the reviewer

The proxy also handles WebSocket upgrades transparently, so HMR continues to work normally.

Heartbeat

While the tunnel is running, the CLI sends regular status updates to keep the connection active. If the CLI stops unexpectedly, the tunnel remains active until manually deactivated from the dashboard or until the next checkpoint start with the same name reconnects.

Plan limits

When creating a new tunnel (not a reconnect), the CLI checks the workspace subscription:

Free plan: max 1 tunnel across the entire workspace
Pro / Enterprise: unlimited tunnels