Watchpost
A self-hosted monitoring system for machines and services, paired with Watchpost Agent for host telemetry and future fleet actions.
Open Watchpost at my.watchpost.cv.
No configured instances: my.watchpost.cv immediately opens localhost:7334, so a normal single local installation needs no launcher setup.
One configured instance: it opens that named instance directly. Two or more: it shows the instance catalog, with each entry storing a name, domain/IP and optional port.
The configuration remains browser-local and can be opened directly even when normal launcher navigation redirects. The planned my.gantry.cv app drawer links into these per-project launchers rather than copying their instance registries.
Know what the machines are doing, then make the next action obvious.
Watchpost monitors the hosts underneath your applications. A Watchpost server receives telemetry from paired Watchpost Agents and turns CPU, memory, disk, service and machine state into a concise operational view. The target experience is calmer than a generic observability stack: enough evidence to understand what is wrong without requiring a monitoring specialist to operate the monitor.
The basic workflow stays extremely small: install Watchpost, install an Agent on the machine, pair them and start receiving health data. Fleet management, configuration propagation, clustering and Cortex-assisted remediation are advanced layers that should appear only when there are enough machines or enough operational complexity to need them.
Watchpost is also the natural connective tissue between Gantry services because it already knows machine identity. A monitored host can advertise the Warden or Cortex instance associated with that machine, turning monitoring into a launch point for investigation rather than a dashboard you abandon as soon as an alert appears.
Useful capability without mandatory complexity.
The project stays focused on its own job; the surrounding Gantry tools remain optional.
See CPU, memory, disk and service-level information for the machines that matter to your applications.
The Agent is the trusted machine-side component. Pairing creates an explicit relationship rather than expecting Watchpost to have arbitrary remote shell access.
Groups of enrolled machines can become targets for common policy or configuration without manually repeating setup on every host.
Direct links to Cortex or Warden can move from “this host is unhealthy” to investigation or repair with the monitored machine already identified.
Start with the shortest path.
Advanced deployment or integration features appear only when the workflow actually needs them.
- 01
Run Watchpost and open
my.watchpost.cv; with no explicit launcher configuration it targetslocalhost:7334. - 02
Install Watchpost Agent on a machine and use the pairing flow to enroll it. The Agent has its own launcher at
agent.watchpost.cv, with the local default on port7335. - 03
Use the overview and machine detail pages to identify resource, service or health problems.
- 04
Where Cortex or Warden is associated with that machine, open the relevant tool in a new tab so Watchpost remains available as the incident context.
Connections that remove real hand-off friction.
Each product already owns one side of these workflows. The integration exists to remove duplicate navigation, setup or context.
Cortex
This is one of the highest-value Gantry connections. A Watchpost incident can offer “Open Cortex” for the affected machine. The first level is navigation; later levels can pass incident evidence, request a read-only investigation, present a proposed fix and finally allow narrowly pre-approved remediation for known classes of failure.
Explore Cortex →Warden
Some incidents need a human at the controls. A Warden link on the machine detail view can open that machine’s development/admin workspace directly while leaving the Watchpost alert visible in the original tab.
Explore Warden →Webfleet
Watchpost sees the host from the inside; Webfleet sees the website or API from the outside. Using both avoids a common blind spot: a process can be running and the machine can look healthy while DNS, TLS, routing or the public endpoint is still broken.
Explore Webfleet →Trestle
A Trestle service is another important workload on a monitored machine. Watchpost reports host and service condition while Trestle remains responsible for application data and API behaviour.
Explore Trestle →Where Watchpost earns its place.
Monitor a handful of machines without introducing a large observability platform.
Group machines, distribute selected configuration and keep operational state visible from one self-hosted control point.
Use Watchpost as the evidence/coordination layer and Cortex or Warden as the place where investigation and repair happens.
Explore Watchpost.
Project-specific installation, commands and release details live on the project site.