App Health, Expiry and Request Limits

A running TSLink node and a healthy backend are separate facts. While its daemon runs, TSLink checks each registered backend and reports health and expiry evidence through CLI status, diagnostics and MCP.

Check useful application behavior

Choose a small, read-only endpoint that checks the dependencies your app needs:

tslink add preview --proxy localhost:3000 --health-path /ready   --health-status-min 200 --health-status-max 299 --health-body ready   --health-timeout 5s --health-interval 1m
tslink status --json
tslink list --verbose
tslink doctor --json

The app must implement /ready. Default HTTP checks use GET /, status 200–299, no body assertion, a 5-second timeout and a 1-minute interval. Redirects are not followed. Body matching checks the first 64 KiB; use a non-sensitive substring. Same-name add replaces other service settings too.

TCP checks connect to the backend; file checks verify the shared path. Backend checks do not prove remote tailnet access, TLS or policy. Test the actual app URL from a permitted receiving device too. Monitoring does not restart your application.

Expiry and owner alerts

Status reports the node's observed key deadline rather than guessing a lifetime. Warnings begin at 14 days, become critical at 3 days, and distinguish unknown deadlines. Credential expiry estimates are labeled separately.

Health changes and expiry thresholds enter a local alert journal. To opt into notifications, create owner-controlled alerts.json in TSLink's config directory (0600 on POSIX), select one command or HTTPS webhook, then restart the daemon:

{"command":["/absolute/path/to/your-notifier","owner-channel"]}

The command receives event JSON on stdin and runs with the daemon's permissions. Delivery is bounded, rate-limited, best effort and at most once; it can be lost and is not retried. These owner-notification limits are not HTTP request-rate throttling. See the TSLink alert guide for event fields and webhook configuration.

Public Funnel has a separate exposure deadline. Use tslink add demo --proxy localhost:3000 --funnel --public --funnel-ttl 1h only for an intentionally public app with suitable application authentication. A new Funnel defaults to 24 hours, with a default 7d public maximum; new public never is refused. See durations. People deadlines apply only to private HTTP/files.

Uploads and request limits

For large photos or videos, choose a finite whole-request bound, including multipart metadata:

tslink add photos --proxy localhost:2283 --max-request-body 20GiB --request-read-timeout 2m

Defaults are 32 MiB bodies, a 10-second header window, a 30-second body-read inactivity window, and 60-second keep-alive idle timeout. --request-header-timeout and --idle-timeout adjust their respective windows. These bound size and inactivity, not requests per second. Streaming responses and WebSocket connections are not limited by the upload window; backend limits still apply.

Removing the body cap requires both --max-request-body unlimited --ack-unlimited-request-body. HTTP middleware rate limiting, Basic Auth, CORS and IP allow lists remain planned.

Sources: TSLink health and alerts, TSLink sharing and request limits.