| Attribute | Example attribute value |
|---|---|
| Team | Product development |
| Service | Payments |
| Customer | Acme Corp |
Priority | P1 |
What attributes enable
Alert routing- Automatically page the right teams based on the alert context. Configure alert routes to use attributes for dynamic routing.
- For example, route alerts to the team owning the affected service.
- Automatically set incident custom fields from alert attributes.
- For example, when multiple alerts are grouped into one incident, the incident’s affected Teams custom field can aggregate all team attributes from those alerts and show which teams were impacted.
- This enables better insights and reporting on incidents.
- Drive automations based on alert context using attributes in workflow conditions.
- For example, use impacted Customer attribute to automatically add the account’s Customer success manager to incidents.
- Another example, use the Github user attribute to page the engineer who last worked on this area.
- Aggregate and analyze alerts across different sources and identify patterns.
- Catalog-powered attributes allow for more granular insights than plain text attributes.
- For example, use feature attribute to analyze which product areas generate the most alerts, helping prioritize reliability work.
- Route alerts to specific Slack or Microsoft Teams channels dynamically based on context.
- For example, use Team attribute to send alerts to the right team channel.
Define attributes
Set up attributes once, use them everywhere. Define which fields matter for your organization:- Using the sidebar, navigate to Settings → Alerts
- Click the Settings icon (gear icon in top right)
- Select Attributes
- Click + Add attribute to create a new attribute (see recommended attributes below)
- Configure the fields:
- Name: What to call the attribute (e.g., Team, Service, Customer)
- Resource type: Link to Catalog types or store as plain text (String)
- Multi-value: Allow multiple values per alert
- Required: Mark as required when this attribute is critical for routing and escalation
- Click Save changes
Recommended attributes
Start with these commonly used attributes to enable powerful routing and automation:| Recommended attribute | Common uses |
|---|---|
| Team | Routes alerts to the right team automatically, tracks which teams are affected across grouped alerts |
| Service | Groups alerts by service for routing and insights, helps identify which services generate the most alerts |
| Feature | Groups alerts by product area, especially useful for insights and analysis, can trigger automations (e.g., update status page for feature outages) |
| Customer | Triggers customer-specific workflows, for example automatically add the account’s CSM to incidents |
Labels | Catch-all for key-value pairs from alert sources, avoids creating 15+ individual attributes for every piece of metadata |
Labels
Labels bundle multiple key-value pairs without requiring individual attribute setup. Alert sources like Grafana, Datadog, and Sentry send lots of metadata (resource_type, cluster, namespace, environment) as labels. Instead of creating a separate attribute for each, use labels to pull through all key-value pairs automatically.
This lets teams add new labels to their monitoring tools without configuring anything additional in incident.io. Labels appear automatically on alerts for debugging and context.
For example, a Grafana alert might include labels as a single alert attribute with information like:
cluster: us-east-1namespace: productionresource_type: podseverity: critical
Required attributes
Mark attributes like Team asRequired to ensure all alerts include critical fields. When required attributes are missing, incident.io notifies admins via email or Slack—helping you catch configuration issues before they break routing.
For example, if your alert routing depends on the team attribute and it’s missing, admins are notified immediately to fix the upstream configuration.
Extract attributes from sources
Extract attribute values from alert payloads when setting up and configuring alert sources. Use AI recommendations, or use custom logic to extract specific attributes.Extract using AI
AI analyzes your alert payload and automatically suggests which attributes to extract, matching fields like Team, Service, or Customer to your defined attributes and existing Catalog entries. To use AI-powered extraction:- Follow the alert source setup steps and navigate to the final stage Configure your setup
- Click Review attributes to see AI suggestions based on your payload
- For each suggested attribute:
- Click Accept to add the attribute extraction (e.g., parse Team from payload)
- Click Skip to ignore the suggestion
- Accepted attributes appear in Your attributes section
Extract with custom logic
Extract specific attributes from alerts or transform values when you need custom logic. To link an existing attribute from the alert source payload:- In the Attributes section during source setup, click + Add
- Select Link an existing attribute and choose an attribute from your catalog
- The attribute automatically maps to matching fields in your payload
- In the Attributes section during source setup, click + Add
- Select Create a new attribute and enter the attribute name (e.g., Team slack channel)
- Write JavaScript (ES5) expression to extract the value from your payload
- Configure the result type (String, Customer, Business functionality, etc.)
$.metadata.team first, then $.labels.team if that’s empty, and finally defaults to “unknown” if neither exists.
FAQs
Why are my attributes missing?
Why are my attributes missing?
When alerts arrive without expected attribute values, click Inspect on any alert to view the original payload, JavaScript expressions, and extraction results.Common causes:
- Inconsistent payloads: Your monitoring tool sends different data structures for different alert types. Add fallback expressions using
||(e.g.,$.metadata.team || $.labels.team) - Missing Catalog entries: For Catalog-powered attributes, text values from your payload must match Catalog entries. Use External IDs as your system’s canonical identifier or add Aliases for naming variations. For example, a team called “Payments” might have aliases “payments”, “paymnts”, and “billing-team” so alerts from different monitoring tools all map to the same Catalog entry.
How do I set up and map priorities?
How do I set up and map priorities?
Create priorities based on alert severity in Settings → Alerts → Priorities. Define priority levels like
P1, P2, P3 that correspond to severity values from your monitoring tools. Use these priorities in alert routes and escalation paths to control escalation behavior.For example, route P1 alerts directly to senior engineers while P2 alerts follow standard escalation.Map incoming severities to priorities:Navigate to Settings → Alerts → Priorities, edit a priority, and add aliases to map incoming alert severities:- P1: Add aliases “critical”, “error”, “urgent”
- P2: Add aliases “high”, “major”
- P3: Add aliases “medium”, “warning”
What's the difference between String and Catalog attributes?
What's the difference between String and Catalog attributes?
String (text) attributes store freeform data like error messages, URLs, or environment names. Use these when you don’t need to link the value to other parts of incident.io.Catalog-powered attributes link to your organizational structure (teams, services, etc.) and enable dynamic routing. When you set an attribute like Team to a Catalog type, you can use expressions like
alert.team.escalation_path to automatically page the correct team.Choose Catalog attributes when you need to route alerts or connect to escalation paths. Choose String attributes for context that doesn’t need automation.When should I use aliases vs External IDs?
When should I use aliases vs External IDs?
External IDs are your system’s canonical identifier—immutable and unique. Set these first as the “source of truth” for each Catalog entry.Aliases handle naming variations. Add multiple aliases to match different ways your monitoring tools refer to the same thing. For example, a team might have External ID
platform-team but aliases “platform”, “platform-eng”, “Platform Engineering”.Use both together: External IDs keep things organized internally, while aliases make sure alerts from different tools all match the same Catalog entry.Where can I see attributes?
Where can I see attributes?
Alert attributes appear across incident.io to give responders context:
- Alerts table (On-call → Alerts) - Scan attributes across multiple alerts
- Alert sidebar - Click any alert to see all attributes, or click Inspect to view raw JSON
- Mobile app, SMS, voice - Critical context when being paged via mobile app, SMS, or voice calls
- Incident channels - View alert attributes as incident context