Conditions, alerts, and parameters

This page completes the monitoring story: how objects and conditions become alerts, and how integrators discover valid metric keys.

Monitoring objects and conditions

Project (and workspace-scoped) routes manage monitoring objects - definitions of what to observe (URLs, clusters, hosts). Conditions attach to objects with:

• A parameter (latency, HTTP status, certificate TTL, CPU, memory, …).
• An operator and threshold.
• Optional aggregation windows to reduce noise.

Reconciliation evaluates conditions on a routine cadence (on the order of minutes by default) and also reacts to configuration changes and human alert actions.

Alerts

When a condition breaches, an alert captures firing state, timestamps, and linkage back to the object. Users with alert-handling permissions acknowledge or resolve alerts depending on deployment rules. Acknowledgments can feed back into background evaluation.

System parameter registry

A system surface exposes a parameter registry: categories, metric names, and defaults. Clients use this to validate condition definitions before create and to build dynamic forms.

Categories include response, timing, ssl, cpu, memory, disk, firewall, service, and more - mirroring what agents and synthetic checks can emit.

Related reading

• Monitoring overview
• Sources and channels
• Technical verification