Know what failed.
Then understand why.

Which tool does what?

The monitoring path.

Host checks and metrics cover infrastructure. Application scenarios check the actual web endpoint with expected status and identity. Groups, tags and discovery feed dashboard selections so that aggregate views can grow without editing fixed lists everywhere.

The NOC summary should be easy to scan: service or host name and state colour, with detailed metrics available in the appropriate view. A dedicated service panel may still target a specific component.

What a web-service check should establish.

1. The production URL is reachable with the expected protocol and valid TLS where applicable.
2. The response code and identifying content belong to the intended application.
3. Response time is collected in context.
4. Persistent failure and absent data are handled distinctly.
5. The service is classified so that it appears in the intended dynamic dashboards and alerts.

This is the onboarding rule for newly promoted services with a URL. A login page probe establishes frontend availability; a functional transaction requires a separate authorised test. An authentication challenge can be an expected response for a protected interface.

The event-investigation path.

The production logging environment was promoted after UAT. The documented managed agents send directly to Elasticsearch. Fleet controls their policies and integrations; it does not mean all data passes through Logstash.

Server events, Docker container logs and Docker metrics are separate sources. Agent health is important, but the stronger check for a required source is a recent event with a trustworthy timestamp and identity. The service guide records the initial cutoff and seven-day retention decisions.

A practical investigation sequence.

1. Start from the failing service and the time window when the symptom began.
2. Check current measurements and whether the data itself is fresh.
3. Follow shared dependencies such as the database, proxy and mounted storage.
4. Search relevant events for the same interval and account for time-zone handling.
5. Form and test a specific hypothesis before changing infrastructure.
6. Validate recovery at the application and record the evidence and limits.

The newest received log is not necessarily the exact failure time. Missing collection, delayed shipping and processing can all affect what is visible.

The notification path has its own dependencies.

Zabbix or Kuma producing an event does not prove that a person received a notification. n8n execution, message transformation, external connectivity and downstream delivery need their own validation. The Kuma VM reduces one monitoring-host dependency, but the complete delivery path is not automatically independent.

What is not a monitoring guarantee.

A running container, HTTP success, green cluster, online Agent and successful backup each describe a particular check. None proves every application function or recovery scenario. This public documentation is a design snapshot, not a live green/red status page.