Create a private location
Create an organization-owned private region for the monitor configuration. Private-region management is currently available on Team and Enterprise; multi-site execution routing should be confirmed with support.
Limited beta · configured relays · Team+
Monitor private services without publishing them to the internet
Private-network monitoring is available to Team and Enterprise beta customers through a support-assisted relay that runs HTTP/HTTPS, TCP, Ping, and DNS checks and communicates outbound over HTTPS. Fresh self-serve relay onboarding is not currently presented as working.
Support-assisted beta
Outbound connection
HTTP · TCP · Ping · DNS
StackEye control planeassignments + results
api.stackeye.iorelay control plane
Private relaysupport-assisted beta
Private networknot publicly routed
HTTP API
TCP :5432
Private DNS
The actual product boundary
The control plane works; onboarding needs repair
StackEye dispatches private-region work and accepts results from existing configured relays. The current fresh-install path has not passed an end-to-end check and is not promised here. 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.
Use a support-assisted beta relay
The polling relay fetches work and submits results over outbound HTTPS, then initiates each authorized check from inside the customer network. Fresh self-serve packaging is currently blocked.
Choose “Internal network”
Create a monitor, choose the internal source, select the private location, and configure the private target and assertion.
Release and install status
Do not copy a stale one-liner
The private-check engine and control plane are implemented, but current self-serve installation surfaces do not reproduce a verified new relay deployment.
- Support-configured polling relays can execute private checks.
- The current relay wizard references installer/image paths that are no longer a verified pair.
- The latest published Station release does not include the scoped private-IP executor fix.
Marketing will call the path self-serve only after a fresh Team/Enterprise enrollment reaches an RFC1918 target and returns a result in production.
private check engine live
polling work/results API live
support-assisted relay supported
fresh self-serve relay not verified
published Station host monitoring onlyPrivate check types
Active checks, not just a heartbeat
A support-configured polling relay receives a target and test definition, performs that check from its location, and sends the measured result back.
HTTP / HTTPS
Request an internal URL and verify status, content, or other configured assertions.
TCP
Confirm that a private host and port accept a connection.
ICMP PING
Test network reachability from the relay’s location.
DNS RESOLVE
Resolve names that may exist only in internal DNS.
SMTP monitoring is supported for public checks, but it is intentionally not a private-region check type.
A separate shipped capability
Station monitors Linux host health
The published Station artifact reports Linux host resources and is managed as a fleet. It is not presented here as the active private-check runner.
- Per-core CPU and physical-memory/swap usage
- Filesystem usage and disk I/O measurements
- Network traffic, packets, errors, and throughput
- Station identity, capability, version, status, and lifecycle controls
Host resourceLatestState
CPUall cores41%reporting
Memoryphysical62%reporting
Filesystem/78%reporting
Networketh0livereporting
Kubernetes scope
Host deployment target today; cluster intelligence still in validation
This distinction matters when a platform engineer asks whether StackEye can find a crash-looping pod behind a green frontend.
- Production-safe claim: deploy Station as a DaemonSet to collect supported Linux node-host signals.
- Development capability: a separate read-only cluster controller, object inventory, endpoint candidates, and probe-to-pod topology UI exist in development.
- Current availability limit: the production frontend does not yet expose the self-serve Clusters route, and the development enrollment UI is not a complete ready-to-apply install flow.
- Therefore: StackEye does not market Kubernetes object/workload awareness as generally available today.
Private monitoring FAQ
Operational details
Does a support-assisted private relay require inbound access?
No. The relay connects outward to the StackEye control plane for work and result submission. You do not expose the private targets or open an inbound control-plane port.
Can a private relay test any private IP?
It executes targets configured for its organization-owned private region. Access is support-assisted for Team and Enterprise beta customers. This page does not claim that the currently published Station artifact performs that job.
Is private monitoring included on every plan?
No. Private monitoring is support-assisted for Team and Enterprise beta customers. Fresh self-serve relay onboarding still needs repair; Station host monitoring is a separate capability with no published per-plan Station-seat limit.
Is StackEye self-hosted?
Station and private relays run in customer environments; the StackEye control plane is hosted. We do not use an installed component to imply that the complete monitoring platform is self-hosted.
Private beta
Need the private-relay capability?
Join the waitlist and describe the targets and network boundary. We will not promise a self-serve install until that path is repaired and verified.
Join the beta waitlist