## TL;DR
A 422 on component status means the status value sent is not in the allowed enum: operational, degraded_performance, partial_outage, major_outage (and under_maintenance where supported). Map your internal states to these values explicitly, validate before sending, and never pass through raw internal strings. The enum is small and fixed; the fix is a mapping table.

## The query

```text
statuspage component status api 422: invalid status value
```

## Use this when

- Component status updates fail with 422
- Automations cannot set component status
- You are building statuspage integrations
- Status values from monitoring do not map

## Not for

- Designing the status page layout
- Writing incident updates
- Managing subscribers
- Choosing status page plans

## Steps

### 1. Check the sent value against the allowed enum

Compare the failing value to the documented statuses character by character. Common failures: "down," "up," "critical," or capitalized variants. The enum is exact; close does not count.

Expected output: the invalid value identified.

### 2. Build an explicit internal-to-statuspage mapping

Map every internal state (healthy, warning, critical, maintenance) to exactly one allowed status. No pass-through of raw values, ever. The mapping table is the contract between your monitoring and the status page.

Expected output: a complete mapping table with no gaps.

### 3. Validate the status before sending

Check the mapped value against the enum client-side before the API call. Pre-send validation turns a 422 into a local error with the mapping table attached, which is debuggable in seconds.

Expected output: pre-send enum validation.

### 4. Handle the maintenance status deliberately

Maintenance is a distinct state with its own semantics (scheduled, expected). Do not overload "operational" or "degraded" for maintenance windows; use the maintenance status where the API supports it, or model maintenance as a scheduled event.

Expected output: maintenance modeled explicitly, not overloaded.

### 5. Log status transitions for the audit trail

Record every status change: from, to, when, and what triggered it. Public status changes are customer-visible commitments; the log explains "why did it say outage at 3am" and debugs flapping.

Expected output: an auditable status-transition log.

## Template: the checklist

```text
Statuspage status 422 fix:
[ ] Failing value identified against the enum
[ ] Explicit internal-to-status mapping table
[ ] Pre-send enum validation
[ ] Maintenance modeled explicitly
[ ] Status transitions logged with triggers
```

## Variant phrasings

### statuspage api invalid status

Steps 1 and 2. Identify, then map.

### component status update rejected 422

Steps 2 and 3. Mapping table plus validation.

### mapping monitoring states to statuspage

Step 2 as the design task.

## Why it happens

Monitoring systems have rich internal state vocabularies (CRIT, WARN, UNKNOWN, MAINT, flapping), and integrations pass those strings straight through to an API with four allowed values. The 422 is the API refusing to guess what "CRIT" means. The mapping table is the translation the integration was missing.

## Edge cases

- Flapping components: rapid state changes spam the status page. Debounce before mapping to a public status.
- Partial versus major outage: define the business rule that separates them (affected user share, severity). Do not leave it to judgment per incident.
- Component groups: group status derives from children. Define the rollup rule explicitly.
- API version differences: confirm the enum for your API version; values can vary.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_wgfW6siZxjQR6wy5G64V2A