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

# Alert attribute merge strategies

> Control how your alert data is captured and updated over time using attributes and merge strategies.

Alerts often fire more than once for the same issue. Each time they do, the payload might contain new information, a severity that's gone from warning to critical, an updated error count, or additional affected services. **Merge strategies** give you control over what happens to each attribute when an update arrives: keep the original value, replace it with the latest, accumulate a list. You can now decide, per attribute, exactly how your alert data evolves.

### What are Alert Attributes?

Attributes are the key pieces of information you pull out of your alert payloads, things like `team`, `service`, `error_message`, or `priority`. They can be a single value (like a team name), a list (like multiple affected services), or a reference to something in your [Catalog](/catalog) (like a Team or Service entry). Once set up, attributes are what your alert routes can use to decide where to escalate and how to create incidents.

### Getting started

1. Head to **Settings → Routing** in the dashboard
2. Click on your alert source (e.g. HTTP, Datadog, PagerDuty)
3. Scroll until you find the attributes section and click **Edit**
4. Click the **cog** next to an attribute to change its **merge strategy**

***

## Understanding Merge Strategies

When the same alert fires multiple times, merge strategies determine how attribute values are combined or replaced. Here's how each of them works:

> **Rankable types** are: Alert Priority, Incident Severity, Follow-up Priority, or custom catalog types with ranking.

| **Strategy** | **Scalar** | **Array** | **Rankable Required** |
| ------------ | ---------- | --------- | --------------------- |
| First Wins   | Yes        | Yes       | No                    |
| Last Wins    | Yes        | Yes       | No                    |
| Accumulate   | No         | Yes       | No                    |
| Maximum      | Yes        | No        | Yes                   |
| Minimum      | Yes        | No        | Yes                   |

***

### First Wins

Keeps the first value ever set for the attribute. Basically, once the value is set it never changes regardless of subsequent alerts. Available for all attribute types.

**Example:** First alert sets `service = "payments"`, second alert sends `service = "checkout"` → result is `service = "payments"`.

Best for preserving original state, like an initial error message or first reported time.

***

### Last Wins

Always updates to the latest value each time an alert with the same de-duplication key fires. This is available for all attribute types and only applies **before** the alert escalates or creates an incident.

**Example:** First alert sets `error_count = "5"`, second alert sends `error_count = "12"` → result is `error_count = "12"`.

Best for tracking current state, like a live error count or status.

***

### Accumulate

Combines all values into a single deduplicated list. This is available for **array attributes only** and applies **before** the alert escalates or creates an incident.

**Example:** First alert sends `affected_services = ["api", "web"]`, second sends `["api", "database"]` → result is `["api", "web", "database"]`.

Best for building up lists of affected services, regions, or endpoints over time.

***

### Maximum

Keeps the highest ranked value. This is available for scalar attributes with **rankable types** only and applies **before** the alert escalates or creates an incident.

**Example:** First alert sets `priority = "medium"`, second sends `priority = "critical"` → result is `priority = "critical"`.

Best for ensuring the most critical priority always wins.

***

### Minimum

Keeps the lowest ranked value. Works the same as Maximum, so only works with rankable types and applies **before** the alert escalates or creates an incident.

**Example:** First alert sets `priority = "critical"`, second sends `priority = "low"` → result is `priority = "low"`.

Best for de-escalating priority when subsequent alerts signal recovery.

***

## When Attributes Stop Updating

Once an alert has created an incident or triggered an escalation, **attribute values are locked**. Any subsequent alert fires will not update them.

This is by design — it ensures your incident data reflects the state at the moment action was taken, prevents confusing mid-incident changes, and keeps your audit trail clean.

| Strategy   | Locks after incident/escalation?      |
| ---------- | ------------------------------------- |
| First Wins | N/A (already locked from first value) |
| Last Wins  | Yes, stops updating                   |
| Accumulate | Yes, stops accumulating               |
| Maximum    | Yes, stops comparing                  |
| Minimum    | Yes, stops comparing                  |

***

## FAQs

<AccordionGroup>
  <Accordion title="What happens if I change the merge strategy for an existing alert source?">
    The new strategy applies to future alert fires only. Existing attribute values are not retroactively changed.
  </Accordion>

  <Accordion title="Can I use different merge strategies for different attributes?">
    Yes! Each attribute can have its own merge strategy, or fall back to the source default.
  </Accordion>

  <Accordion title="What are rankable types?">
    Types that have a defined ordering. Built-in rankable types are Alert Priority, Incident Severity, and Follow-up
    Priority. Custom catalog types can also be marked as rankable.
  </Accordion>

  <Accordion title="Why don't my attributes update after an incident is created?">
    Attributes lock when an incident or escalation is created — this ensures the incident reflects the state at the time action was taken.
  </Accordion>
</AccordionGroup>