You do not need application instrumentation to answer a basic operational question: “Is this API reachable, and is it slower than normal?” A self-hosted synthetic monitor can send the same request on a schedule, record its duration and alert after a sustained failure or regression.
This is not a replacement for APM. It cannot show a slow database span or a hot function. It provides an outside-in signal that still works when telemetry inside the application is broken.
The minimum useful setup
Monitor a stable endpoint with:
- an explicit timeout;
- the expected HTTP status codes;
- required headers or authentication;
- a 30–60 second interval for production services;
- consecutive-failure confirmation;
- separate down and degraded states.
Run the monitor from a network path that represents what you need to validate. A Warden instance in your homelab measures the path from that homelab. It does not claim global or browser performance.
Fixed thresholds versus learned baselines
Use a fixed threshold when the API has a documented response-time objective. For everything else, one global number is usually wrong: 500 ms may be disastrous for a local health endpoint and normal for a remote third-party API.
Warden learns P50 and P95 separately for each monitor after enough successful samples. Its default adaptive threshold is the greater of P95 × 1.5 or P95 + 100 ms. An explicit per-monitor threshold always wins. See the adaptive latency documentation.
What you gain by self-hosting
The monitor can reach private APIs, its history stays on infrastructure you control, and the cost does not scale per check. The tradeoff is equally important: you operate the observer, database, backups and network path. If that observer disappears, it cannot tell you the world is down.
Warden packages its Go backend and web UI in one binary, uses SQLite by default and also supports PostgreSQL. It checks HTTP, TCP, ping, DNS and Docker containers. For API checks you can configure methods, headers, bodies, accepted status codes, redirects, timeouts and retries.
Know when to add APM or another location
Add APM when you need code-level root cause. Add a second independent observer when a single location is an unacceptable blind spot. Add browser monitoring when Core Web Vitals and rendered page behavior matter.
Start with the smallest signal that answers your current incident question. A reliable external response-time series often catches regressions before a full observability migration is justified.