Webfleet
A web and API workbench and monitoring tool for checking the public-facing behaviour of websites and endpoints.
Open Webfleet at my.webfleet.cv.
No configured instances: my.webfleet.cv immediately opens localhost:7336, 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.
Monitor what users can actually reach, not only what the server thinks is healthy.
Webfleet looks at websites and APIs from the network side. It combines an HTTP/API workbench with ongoing monitoring so the same product can help you inspect an endpoint manually and then keep watching it over time.
That outside-in perspective complements host monitoring. DNS can be wrong, TLS can expire, a CDN can behave differently by region, or a route can fail even though the process and machine are both healthy. Webfleet makes those failures visible as web failures rather than forcing an operator to infer them from infrastructure metrics.
The distributed-worker direction strengthens that idea rather than changing it. One instance can monitor from one place; multiple workers can answer whether the same endpoint behaves differently from Melbourne, London, New York or another network location.
Useful capability without mandatory complexity.
The project stays focused on its own job; the surrounding Gantry tools remain optional.
Inspect requests and responses directly instead of treating the monitor as a one-way alert generator.
Track pages and endpoints over time and keep failure details close to the check that produced them.
Surface public-facing resolution and certificate problems that an internal service monitor may never see.
Regional workers can provide independent observations while clustering keeps the coordinating service available.
Start with the shortest path.
Advanced deployment or integration features appear only when the workflow actually needs them.
- 01
Open
my.webfleet.cv; zero launcher configuration targetslocalhost:7336. - 02
Add the pages, APIs or public checks you actually care about rather than mirroring every internal process.
- 03
Use Webfleet’s detailed failure view to decide whether the issue is application behaviour, DNS, TLS or connectivity.
- 04
Correlate with Watchpost when the service is yours: external failure plus a healthy host suggests a different investigation path from external failure plus a degraded host.
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.
Watchpost
Watchpost and Webfleet provide two independent observation planes. Watchpost says what the host and service report internally; Webfleet says what the public network sees. Correlating the two gives much better incident triage than either signal alone.
Explore Watchpost →Cortex
A failing page or API can become a focused Cortex investigation: inspect the relevant project, reproduce the request, run tests and propose a fix while the original Webfleet evidence remains available.
Explore Cortex →Warden
When the fix requires hands-on editing, Warden can provide the persistent remote workspace on the machine or repository where the affected application is maintained.
Explore Warden →Where Webfleet earns its place.
Watch a small set of sites and APIs without outsourcing the data to a hosted monitoring provider.
Track externally visible behaviour alongside host monitoring and application logs.
Add distributed workers when geography actually matters, rather than making every one-node installation configure regions.
Explore Webfleet.
Project-specific installation, commands and release details live on the project site.