Monitoring and alerting (user scope)

Loopback provides monitoring objects, conditions, alerts, and notification channels so teams can observe endpoints and infrastructure without building a separate Prometheus stack first (though you still can on-cluster).

Organization-level building blocks

Monitoring sources
Catalog entries describing where probes run from (agents, external vantage points). Reconciliation can check source health when agents or hosts change.

Notification channels
Destinations for alert delivery (webhooks, email integrations — exact types deployment-specific). Configured with filters such as severity or internal-only routing.

Project-level monitoring objects

A monitoring object defines what to watch:

• Target — URL, host, Kubernetes cluster reference, etc.
• Type — HTTP, SSL, Kubernetes, host metrics, …
• Enabled flag and state.

Conditions attach to objects:

• Choose a parameter (latency, status code, certificate days to expiry, CPU, …).
• Choose an operator and threshold.
• Optional aggregate windows for noisy metrics (e.g. require N samples over 15m).

Alerts materialize when conditions breach; lifecycle includes firing, acknowledged, resolved semantics in data model paths.

Permissions

• Configure objects/conditions — project.monitoring_object family.
• Interact with alerts — project.monitoring.alert (read/ack depending on role design).

System monitoring parameters

Operators and advanced users can fetch the parameter registry that enumerates valid metrics, categories, and defaults — useful when building conditions in UI or automation.

Platform health (internal / operator)

Some routes aggregate monitoring alerts and monitoring object states into a platform scorecard (PoC / status endpoints). Customers may or may not see this surface — depends on product packaging.

Related reading

• Reconciliation
• Notification channels org scope
• Platform stubs (legacy short page)