---
title: "App Health, Expiry and Request Limits"
description: "Check backend readiness, see expiry warnings, opt into owner alerts and configure finite upload limits."
url: "https://tslink.md/docs/health-and-alerts"
locale: "en"
product_version: "0.1.1"
source: "https://github.com/anydoor7/tslink/blob/v0.1.1/docs/health-and-alerts.md"
---

> Documentation index: https://tslink.md/llms.txt · Installed binary is authoritative: `tslink manifest`.

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:

```bash
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.

| Observation | Meaning                                                |
| ----------- | ------------------------------------------------------ |
| `healthy`   | Most recent check succeeded                            |
| `degraded`  | One or two consecutive failed checks                   |
| `down`      | Three consecutive failed checks                        |
| `unknown`   | No current usable observation, including a stale check |

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:

```json
{"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](https://github.com/anydoor7/tslink/blob/v0.1.1/docs/health-and-alerts.md) 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](https://tslink.md/docs/durations.md). 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:

```bash
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](https://tslink.md/docs/experimental-roadmap.md#middleware).

Sources: [TSLink health and alerts](https://github.com/anydoor7/tslink/blob/v0.1.1/docs/health-and-alerts.md), [TSLink sharing and request limits](https://github.com/anydoor7/tslink/blob/v0.1.1/docs/sharing.md).