Health
A CI has a health, in the same words as a service: Operational, Maintenance, Degraded or Outage.
From incidents and changes
A CI's own health comes from the records that name it, while they are open:
| On the CI | Its health |
|---|---|
| An open P1 incident | Outage |
| An open P2 or P3 incident | Degraded |
| A change in progress | Maintenance |
| None of these | Operational |
The worst one wins, and a P4 incident doesn't change it. The Health now card says which records set it (“From its open incidents and changes: INC-7 (P2)”), and the CI's Work on it card lists them. When they are resolved or finished, the CI is operational again on its own.
How trouble spreads
When a CI is degraded or has an outage, the desk follows its relationships upwards along every kind that spreads trouble (Runs on, Hosted on, Contains and Depends on) and puts what relies on it at risk: “At risk through db-prod-01”. That reaches the application service that runs on it and every service that depends on that one, all the way up, and other CIs along the way.
A retired CI is skipped: its trouble doesn't spread, and nothing is at risk through it.
Setting it by hand
With Set configuration item health (ci.status), or as its owner, the CI's page has Set health… on its
Health now card. Pick the health, say why, and for how long it holds (up to a week). A health set by hand wins
over what incidents and changes say. When the time runs out, or Set it back ends it sooner, the CI goes back to
the health its incidents and changes give it. Use it for a disk you know is failing, or a database under maintenance
without a change.
Every change of a CI's health is kept in its Health history, with who or what set it, why and until when, and is
sent as the cmdb.ci_health_changed webhook.