Resources and Kinds
The declarative, git-authored half of upzero's configuration, and what's registered today.
Resources and Kinds
Some configuration in upzero can be written to a file, committed to a
repository, and reconciled into your organization on push, the same shape as
a Kubernetes manifest: an apiVersion, a kind, a metadata.name, and a
spec. upzero calls each of these a Kind. This is
Configuration as code; this page is about what
a Kind is and which ones exist.
Three ways a resource gets written
- Declared, a manifest in git, reconciled on push. There is deliberately
no
up0 applycommand; the only way in is a real repository and a real push. - Discovered, the ingest pipeline notices something, such as a service's name in your telemetry.
- Interactive, created through the console or the API directly, the way your first monitor was.
A Kind is always the declared path. Some Kinds also have an interactive path today; some don't yet, and can only be reached through git once their console or API support lands.
Look up a Kind's fields yourself
up0 schema explain MonitorMonitor.spec (up0.io/v1)
┏━━━━━━━━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ FIELD ┃ TYPE ┃ REQUIRED ┃ DEFAULT ┃ NOTES ┃
┡━━━━━━━━━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ type │ string │ no │ http │ Monitor type: http, tcp, │
│ │ │ │ │ ping, dns, heartbeat, │
│ │ │ │ │ browser │
│ url │ string │ no │ │ URL to monitor (format │
│ │ │ │ │ depends on type) │
│ intervalSeconds │ integer │ no │ 300 │ Check interval in seconds │
│ │ │ │ │ (10-3600) │
│ serviceId │ string │ no │ - │ Soft-bind this monitor to a│
│ │ │ │ │ service catalog entry │
│ config │ object │ no │ {} │ Type-specific config │
│ │ │ │ │ (JSONB), keyed on `type` │
└─────────────────┴─────────┴──────────┴─────────┴─────────────────────────────┘The seven Kinds registered today
| Kind | What it declares |
|---|---|
Monitor | An uptime check: type, URL, interval, optional service binding |
Tag | An org-level label monitors can reference by name |
Rule | A metrics condition that produces an alert when it matches |
Service | Annotations on a discovered service: owner, tier, environment, repo, runbook, dashboard links. It never creates the service itself; annotating a name discovery has never seen is refused |
StatusPage | A public status page: components, and maintenance windows |
Objective | An SLO: a target ratio over a signal source, and the window it's measured on |
Dashboard | A saved dashboard's panels and layout |
Organization is also in the registry, but only for drift detection. It's
never applied from a manifest, because your organization already exists by
the time you can author one (see create your
account).
Named but not yet supported
A few Kinds are documented as the eventual full set and are deliberately not registered yet, each for its own reason, usually that the piece of the product it would configure has no create model of its own yet to generate a spec from. Naming one in a manifest, or asking the CLI to explain it, doesn't read as a typo. It reads as "not yet":
up0 schema explain WorkflowError: kind "Workflow" is not yet supported — no `*Create` Pydantic model
exists yet to generate a spec model from — `create_workflow` validates a raw
dictThe Kinds in that state today: Workflow, IngestionToken,
EscalationPolicy, DataView and IssuePolicy.