Private network monitoring: capability, relay, and release boundary

An external uptime checker can only initiate a check to a target it can reach. That is exactly what you want for a public website, but it leaves a real design need for internal APIs, private ports, appliances, and DNS names that exist only inside a customer network.

The active-relay model

StackEye has a separate customer-run polling relay that can execute authorized checks from the private side of the boundary:

StackEye work/results API
        ^ outbound HTTPS
        |
support-assisted beta relay
        |
        +-- HTTP  api.internal
        +-- TCP   database.internal:5432
        +-- Ping  switch.internal
        +-- DNS   service.corp

For Team and Enterprise beta customers, the support-assisted relay can perform HTTP/HTTPS, TCP, ICMP Ping, and DNS-resolution checks. SMTP remains a public-check type and is intentionally excluded from private-region execution.

The current availability boundary

This capability is not currently a fresh self-service workflow. The authenticated relay-creation API is Team-gated, while the current product UI provisions Station instead of the released private-relay agent. The default installer, image tags, and generated CLI hint do not form a verified new-customer path today.

Strict site affinity is not promised during beta. If a configured region has no active bound relay, current assignment logic can use another active private relay in the same organization, so multi-site routing should be confirmed with support.

That means the accurate claim is narrow: Team and Enterprise beta customers can use the supported checks through a support-assisted polling relay. StackEye should not promise a one-line install, instant enrollment, or a working self-serve private monitor until a fresh production E2E check proves it.

Station is separate today

The published StackEye Station reports Linux host health: CPU, memory, filesystem, network, and supported sensor telemetry. The latest public Station release does not contain the private-IP execution fix, so it is not the private-check runner described above.

StackEye's product model is converging these roles, but marketing should follow released behavior rather than the intended architecture.

What this does not imply

Private checks are configured targets, not automatic service discovery. Neither a relay nor Station makes StackEye a full logs, traces, or APM platform, and deploying Station in Kubernetes is not equivalent to generally available Kubernetes object monitoring.

Read the current private-monitoring status. StackEye is in private beta; join the waitlist to discuss the support-assisted Team and Enterprise relay path or evaluate Station host monitoring.