Endpoints
Creating an Endpoint
Open Endpoints in the dashboard and click New Endpoint. The form picks a root domain; everything else (TLS, agent provisioning, traffic policies) defaults sensibly and can be tuned per-endpoint after creation.
Root domain
The Root domain dropdown decides where your endpoint is published and whether you can pick a custom endpoint name.
| Option | When you'd pick it | Endpoint name |
|---|---|---|
| Default (<your-plan's-domain>, shared) | No setup needed — you just want a public URL. This is the domain your plan provisions on; the dashboard shows it in the option label. | Auto-generated (memorable word-word-word identity). Custom names are not available on shared domains. |
| <other-system-domain> (shared) | Your plan also grants access to additional shared domains. Pick one if you want a different public TLD than the plan default. | Auto-generated (same rule — the (shared) tag means you don't own the domain). |
| <your-custom-domain> (no tag) | You added the domain under Domains, verified it via DNS, and want your endpoint at app.yourcompany.com. Requires a plan that allows custom subdomains. |
Custom — type the subdomain (or @ for the root) when the field appears. |
Why “Default” is also (shared): the dropdown's first option represents your plan's default system domain. You don't own the domain — the platform does — so it's still a shared domain. The Default qualifier just tells you “this is what you'd get if you didn't pick anything”; shared tells you “name is auto-generated, custom names require a domain you own.”
Where the default comes from. Admins set a default system domain per plan; if a plan has no default configured, endpoints created without picking a domain fall back to the service's base host. The dropdown always reflects whatever is current for your plan.
Endpoint Overview
The endpoint Overview tab provides quick toggles and health monitoring.
What's exposed
The top of the Endpoints list shows how many of the account's endpoints (across every page) don't require a login — anyone with the URL reaches them — and how many are protected by a token, password, JWT or SSO login. Show open endpoints lists the open ones with an Add a login link to each one's Authentication tab, and Secure them with Iris hands the job to Iris, which also sets up the tokens or users a login needs so nothing gets locked out. Being open is expected for public sites and APIs; add a login to anything private.
Quick Toggles
- Force HTTPS — Redirect HTTP → HTTPS (301). Enabled by default.
- Response Cache — Enable edge caching with configurable path regex. Shows active cache entries count. Use the Purge button to clear cached responses.
Endpoint Health
Health monitoring sends a periodic HTTPS GET to a path on your endpoint and records the response. The dashboard surfaces uptime, latency and the latest probe verdict so you can spot issues without external monitoring.
Tunnels and apps. Health checks watch endpoints served by an agent and the endpoints of an app (static sites, backends, full-stack apps, WordPress sites and functions), with the same settings. On an app endpoint, your visitors' sign-in and firewall rules don't block the check. An app's Overview tab shows the uptime of each of its endpoints, and its Domains tab a Health column. The probe requests your endpoint's own address, the domain itself for an apex endpoint, and an endpoint without a domain is never probed. This is separate from a backend's own health-check path, which decides when a new deploy is ready.
- Down after two failed checks. Every endpoint, tunnels and apps alike, is marked down only after two failed checks in a row; one failed check after a good one keeps it up, but still counts in its uptime. An endpoint's very first check decides on its own.
- Status only, from one place. A check looks at the status code, not the page content, and runs from one place in our network, so it doesn't tell you whether every region reaches your endpoint.
- Functions asleep. A function that is idle shows Asleep and counts as up. The check doesn't wake it, so its code is tested again only when a visit wakes it.
- Paused apps. A paused app records no checks; its status picks up again once it runs. An app with no live deploy yet is checked once one is live.
- Data-transfer allowance. While your account is over its data-transfer allowance, its app endpoints show down: visitors get a
429too, until the period resets.
Disabled by default. Each endpoint starts with health checks off; enable per-endpoint from the Overview tab when you want monitoring.
HTTP only. Health checks currently support HTTP/HTTPS endpoints. TCP and UDP endpoints show a "not available" notice in place of the settings — we can't sensibly HTTP-probe a non-HTTP service.
Settings
| Field | What it does | Default / Range |
|---|---|---|
| Enable health checks | Turns probing on/off for this endpoint. When off, no probes are sent and existing uptime cards are hidden. | Off |
| Probe path | The HTTP path each probe requests. Use a check path that answers directly, such as /health: the probe doesn't follow redirects, so a path that redirects (to a login page, or from /health to /health/) is reported as up without your app being checked. |
/ — must start with /, max 255 chars |
| Interval | How often a probe runs, in seconds. Each endpoint is probed independently — one probe failing doesn't block the next. | 60 s — minimum 60, maximum 86 400 (1 day) |
Changes take effect within about 30 seconds — the worker reconciles its schedule against the database on that cadence.
Status badge
The badge in the Endpoint Health card shows the current verdict:
- Healthy — the endpoint is up: the last probe returned 2xx, 3xx, 401, or 403, or only one probe in a row failed. A redirect counts as up because the probe doesn't follow it; 401/403 count as up because the endpoint is reachable, it just requires auth.
- Asleep — a function that is idle; it counts as up and wakes on the next visit.
- Unhealthy — two probes in a row failed, and the last returned a 4xx (other than 401/403) or 5xx.
- Error — two probes in a row failed, and the last didn't get an HTTP response (connection refused, TLS error, timeout).
- No Agent Connected — a tunnel endpoint with no agent online. Probing is paused until an agent reconnects. The badge takes precedence over the last probe verdict in this state.
- App paused / No deploy yet — an app endpoint whose app is paused, or has no live deploy yet. Nothing is recorded until the app runs.
- Awaiting first probe — health checks were just enabled; the first probe hasn't run yet.
Metrics
- 24h / 7d / 30d Uptime — Percentage of probes in the window that were up (Healthy or Asleep). Colored green (≥99%), amber (≥95%), or red (<95%).
- Avg Latency — Mean response time across healthy probes in the last 24 hours.
- Last check — Status, HTTP code, latency, timestamp, and (on failure) the error message from the most recent probe.
Health-check probes don't count against your usage and don't appear in your traffic log.
- calm-otter-91.ngris.devAdd a login
/).Traffic Policy
Define rules to control, modify, and route traffic at different lifecycle phases. Traffic policies are configured per-endpoint in the dashboard under Endpoint Settings → Traffic Policy.
Lifecycle Phases
Rules are organized into four phases, each evaluated at a different point in the request lifecycle:
| Phase | When | Available Rules |
|---|---|---|
| on_tcp_connect | TCP connection established | IP Restriction, Rate Limit |
| on_udp_connect | UDP stream begins | IP Restriction, Rate Limit |
| on_http_request | HTTP request received, before forwarding to backend | All rules except Custom Error |
| on_http_response | Response received from backend, before sending to client | Add/Remove Headers, Webhook, Custom Error |
Rule Evaluation
- Rules within a phase are evaluated in priority order (lowest number first)
- Each rule can be toggled ON or OFF independently
- Rules are enforced at the edge before traffic reaches your service
Endpoint API Keys
Manage API keys for edge-level validation. Use with the API Key Validation traffic policy rule. Configured in Endpoint Settings → API Keys. Keys are prefixed etk_ and hashed with SHA-256. Maximum 50 keys per endpoint.
Creating Keys
| Field | Description |
|---|---|
| Name | Descriptive label (e.g., "Production Key") |
| Rate Limit | Max requests/second. 0 = no per-key limit. |
| Expires In | Days until expiry. Empty = no expiry. |
X-API-Key header, api_key query parameter, or cookie — depending on the rule's key_location setting.
| Name | Key | Status |
|---|---|---|
| Production Key | etk_7f3a... |
Active |
| Partner sandbox | etk_2c91... |
Disabled |
Dedicated Ports
Reserve fixed TCP/UDP ports for your endpoint. Your tunnels will always use the same port, even after restart. Configure in Endpoint Settings → Dedicated Ports.