Model a service
A Nexus Point evaluates conditions against existing monitors. For example, an API service may depend on a web health check and a database TCP check. Keep raw monitors for diagnosis and use the Nexus Point to describe whether the combined service is usable.
Free organizations can create one Nexus Point. Pro allows unlimited Nexus Points.
Create a Nexus Point
- Use the dashboard's Nexus Point creation control and enter a name and optional description.
- Add a condition and choose its dependent endpoint.
- Select the condition type. For a latency comparison, enter the threshold in milliseconds.
- Mark the condition critical if its failure means the service is down. Leave it non-critical if failure should mean degraded service.
- Review alert settings and save. Open the Nexus Point detail page to inspect the evaluation and the dependent checks.
The form supports up to ten conditions. Use clear service boundaries so a single signal remains understandable.
Condition types
| Condition | Passes when |
|---|---|
| Must Be UP | The dependent endpoint's status is UP. |
| Must NOT Be DOWN | The dependent endpoint's status is not DOWN; this is weaker than requiring UP. |
| Latency Less Than | Recorded latency is strictly below the threshold. |
| Latency Greater Than | Recorded latency is strictly above the threshold. |
A paused endpoint does not satisfy “Must Be UP” or latency conditions, but can satisfy “Must NOT Be DOWN”. Choose deliberately: “not down” does not prove a recent successful check.
Aggregate status
A failed critical condition makes the Nexus Point DOWN. When critical conditions pass but a non-critical condition fails, the state is DEGRADED. Passing conditions produce UP. Pending or unknown states can occur before evaluation or when usable configuration is absent. Open the individual conditions to understand the result rather than inferring it from the aggregate label alone.
Alerts and changes
The Nexus Point form offers muting and alerts on degraded state. Create a Nexus Point route in Settings → Alerts to deliver aggregate transitions to a destination. Endpoint routes and Nexus Point routes cover different signals; decide which should page your team to avoid unnecessary duplication.
After changing a condition, review the next evaluation. Before deleting a dependent monitor, update the Nexus Point so its intended service definition remains valid.