Kind reference

Rule

Field reference and a complete example manifest for the Rule Kind.

Rule

A threshold alert evaluated against ingested metrics. metadata.name is the natural key, unique per organization. This is metrics only today; log- and trace-based rules have a different condition shape and are not built yet.

Not PromQL. upzero's own Prometheus exists only for the probe engine's synthetic checks, a separate system from ingested telemetry. A Rule is instead a structured aggregation-and-threshold condition, evaluated by a worker that runs one parameterized query per rule against the same tenant-scoped Query API the console and up0 tail use.

Fields

Generated from up0 schema explain Rule --version v1 --output json against a live deployment.

FieldTypeRequiredDefaultMeaning
metricstringyes-The exact metric name this rule evaluates, matching what your app actually emits.
filtersobjectno{}An exact-match label filter against the metric's own labels. No regex, no negation.
aggregationstringnoavgOne of avg, max, min, sum, count.
windowSecondsintegerno300The aggregation window, ending now, evaluated on every tick.
conditionstringyes-One of gt, gte, lt, lte, eq, neq.
thresholdnumberyes-The value condition compares the aggregation against.
forSecondsintegerno0How long the condition must hold, sustained, before the rule fires.
keepFiringForSecondsintegerno0After the condition clears, how much longer to keep firing before resolving.
evaluationIntervalSecondsintegerno60How often the worker re-evaluates this rule.
severitystringnowarningOne of info, warning, critical.
labelsobjectno{}Free-form, carried onto whatever fires from this rule.
annotationsobjectno{}Free-form, carried onto whatever fires from this rule.
groupByarray of stringno[]Label keys to evaluate the condition separately per distinct value of, rather than across the whole metric.
isEnabledbooleannotrue

Example

# up0/rules/payments-api-high-latency.yaml
apiVersion: up0.io/v1
kind: Rule
metadata:
  name: payments-api-high-latency
  labels:
    team: payments
spec:
  metric: http_request_duration_ms
  filters:
    service.name: payments-api
  aggregation: avg
  windowSeconds: 300
  condition: gt
  threshold: 800
  forSeconds: 300
  evaluationIntervalSeconds: 60
  severity: warning
  isEnabled: true

No direct apply path outside a sync

Rule has no REST create or update endpoint; the only route reachable today is GET. Its manifest example above validates cleanly against the live schema, but applying it needs a connected repository, which the local walk that verified this page's other examples could not complete (see Connect a repository). Plan limits apply per organization tier the same way Workflow's do.

Firing reuses the workflow engine

A Rule crossing from pending to firing, once forSeconds has elapsed, emits an event a Workflow can trigger on, the same mechanism a monitor going down already uses. There is no second, parallel notification system for telemetry alerts.

On this page