> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scaling.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Components

> Model the services, databases, and dependencies that make up your system, then tag incidents with the components they affect.

A **component** represents a piece of your system that can fail — a service, a database, a queue, a third-party dependency. Components live in your organization's catalog and can be attached to incidents, status pages, and integrations.

Tagging an incident with the components it affects gives responders a clear picture of blast radius and gives your customers a consistent view of which parts of the product are degraded.

<Frame caption="The components catalog in Settings → Components">
  <img src="https://mintcdn.com/scalingcloud/5-FlXcH6ySIwHzG0/images/placeholder.svg?fit=max&auto=format&n=5-FlXcH6ySIwHzG0&q=85&s=18ab9c45531fe92b117df1f9652cb357" alt="Components catalog" width="1200" height="675" data-path="images/placeholder.svg" />
</Frame>

## Component fields

| Field         | Required | Notes                                                                                                       |
| ------------- | -------- | ----------------------------------------------------------------------------------------------------------- |
| `name`        | Yes      | 1–100 characters. Must be unique within your organization.                                                  |
| `description` | No       | Short context about what the component is and what depends on it.                                           |
| `groupLabel`  | No       | A grouping label (e.g., `Platform`, `Payments`). Used on public status pages to cluster related components. |

## Tagging incidents with components

When you create or update an incident, you can attach one or more components from the catalog. The attached components appear on the incident detail view and — when the component is included on a published status page — drive the status shown to your customers.

```json theme={null}
{
  "title": "Payment service latency spike",
  "severity": "high",
  "componentIds": ["cmp_01j...", "cmp_02k..."]
}
```

You can also update the set of affected components on an existing incident:

```bash theme={null}
curl -X PUT https://api.scaling.cloud/v1/incidents/{incidentId}/components \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"componentIds": ["cmp_01j...", "cmp_02k..."]}'
```

Sending an empty array clears all tags from the incident.

<Note>
  Affected components are **descriptive**. Tagging a component on an incident does not change who gets paged — that is still controlled by the incident's escalation policy. To page a specific team based on a component, configure your escalation policy accordingly.
</Note>

## Inline component creation

If you reach for a component while creating an incident and it isn't in the catalog yet, admins can add it inline from the incident form. The new component is created and immediately attached to the incident.

<Tip>
  Keep your catalog focused. A handful of well-named, customer-recognizable components (e.g., **Dashboard**, **API**, **Payments**) is more useful than one entry per microservice.
</Tip>

## Deleting components

You can delete a component from the catalog at any time. Deleting a component:

* Removes it from every incident's affected-components list.
* Removes it from any status pages that included it.
* Cannot be undone — the component is gone, including from the audit trail of past incidents.

<Warning>
  A component cannot be deleted while it is mapped to an active integration (for example, an AWS CloudWatch integration). Remove or remap the integration first.
</Warning>