Internal URL monitoring deployment and trust runbook
One authoritative path for monitoring 10–20 internal HTTP/HTTPS endpoints: define endpoint semantics, deploy Uptime Kuma, set retry and maintenance policy, add TLS/auth checks, alert, retain history, and prove the monitor with a controlled outage.
Good For
small internal web application monitoring
HTTP health endpoint checks
TLS certificate-expiration monitoring
Uptime Kuma deployment
proving alerts and recovery behavior
How to Use It
Inventory each URL with owner, expected status/response, normal response time, authentication requirement, and maintenance window; do not equate host ping with application health.
Choose an endpoint that represents the service: a health endpoint when available, otherwise a page whose HTTP behavior is meaningful.
Deploy Uptime Kuma using the existing Docker Compose project from a monitoring host that can reach the internal services.
Create HTTP/HTTPS monitors with explicit expected success semantics; TCP-open alone is insufficient when the application can return an error page.
Set a concrete retry/consecutive-failure policy appropriate to the service so one transient miss does not alert without context.
Configure notification delivery and test it with a non-production destination.
Enable certificate-expiration checks and document authentication requirements; use least privilege for authenticated checks.
Configure maintenance windows or planned-downtime handling.
Retain response-time and availability history long enough to identify recurring degradation.
Perform a controlled outage/recovery test and prove detection, notification, recovery, and history behavior.
Periodically test the monitoring system itself so stale monitors, broken notifications, DNS changes, expired credentials, or a dead monitor do not create false confidence.
Execution Modes
- local
Inputs and Outputs
Inputs
- 10–20 internal URLs
- service owners
- expected HTTP behavior
- notification destination
- maintenance windows
- TLS/authentication requirements
Outputs
- operator-notes
- dashboard
- log-file
Validation
Every monitored URL has explicit application-level success semantics.
Retry/consecutive-failure behavior and maintenance handling are documented.
TLS expiration and authenticated-check requirements are addressed where applicable.
A controlled failure produces the expected alert and recovery notification.
History shows the outage and recovery.
Host metrics are treated as separate from HTTP/application endpoint health.
Reporting
Keep an endpoint inventory with owner, purpose, expected response, alert policy, and maintenance handling.
Capture controlled-outage timestamps for failure detection, alert delivery, recovery, and history.
Review recurring response-time degradation separately from hard-down incidents.
Safety Notes
Use a test endpoint or approved window for controlled outage validation.
Do not store privileged reusable credentials when a least-privileged or unauthenticated health endpoint can be used.
Availability monitoring does not replace host, dependency, or application telemetry for deeper diagnosis.