Compute Resources and Alerting API¶
Compute resources provide worker capacity for product workloads. Alerting routes manage receivers, rules, and notification history. The two APIs are operationally related, but an alert is not a substitute for checking the workflow, SQL, or source-task state that produced it.
Compute resource lifecycle¶
Method and route |
Purpose |
|---|---|
|
List available specifications |
|
List selectable worker images |
|
Create a compute resource |
|
List workspace resources |
|
Read one resource |
|
Update it |
|
Inspect deletion dependencies |
|
Delete it |
|
Suspend capacity |
|
Resume capacity |
|
Retry a failed lifecycle action |
|
Read resource metrics |
Specifications themselves have management routes, including create, update, enable/disable, and a management-permission check. Those calls are administrative; do not expose them to an ordinary workspace operator unless the deployment’s authorization contract permits it.
Create, resume, suspend, retry, and delete can be asynchronous. Retain the resource ID and read detail until the documented target or terminal state. Before delete, always call preflight and explain bound workflows or active work. A forced delete, when supported by the deployment, requires explicit confirmation.
Choose CPU, memory, replicas, image, and auto-suspend settings only from the deployed specification. Do not infer units or invent an image tag. When a node remains queued, correlate resource state and metrics with the workflow execution rather than repeatedly creating new capacity.
Administrative compute routes under /newmoi/admin/compute-resources use
broader scope and require separate authorization.
Alert receivers¶
Receiver routes under /newmoi/alerting/receiver cover supported notification
types, list/detail, create, update, and delete. Receiver payloads can contain
email addresses, webhook targets, or other sensitive destinations. Validate
the destination and ownership before enabling it, and do not echo secrets in
logs.
Alert rules and history¶
Route |
Purpose |
|---|---|
|
Read rule templates/default information |
|
List rules |
|
Create a rule |
|
Update a rule |
|
Delete a rule |
|
List alert history |
|
Mark a history group as read |
Expression IDs, levels, categories, thresholds, silence behavior, receiver types, and notification intervals must come from the deployed schema and default-info response. Do not construct an arbitrary expression or assume a unit for thresholds.
Alerting routes are registered, but some deployments hide the alerting main menu while frontend/backend integration is incomplete. A route responding to a manually entered URL is not proof that production notifications are enabled. Confirm module availability, delivery configuration, and a real test notification before relying on alerting.
Marking history as read changes only acknowledgement state; it does not resolve the underlying incident. Retain the alert group/rule ID, time range, workspace, and related execution or resource ID for diagnostics.
Workflow execution controls are documented in Workflows and lineage.