Feature request: Add native Rootly notification integration

Feature request

Add a native rootly_configs receiver to Alertmanager, similar to the existing integrations for PagerDuty, Opsgenie, and incident.io.

Why

Rootly is an incident management platform used by companies like Cisco, NVIDIA, Tripadvisor, and LinkedIn to manage on-call, incidents, and postmortems. Rootly already supports Alertmanager via the generic webhook_configs receiver, but we're requesting a native integration for the following reasons:

1. Simpler configuration for users

Today, configuring Rootly requires users to manually set up Bearer token auth via http_config.authorization — a pattern that's error-prone and less discoverable than a dedicated rootly_token field:

# Current (webhook)
receivers:
  - name: rootly
    webhook_configs:
      - url: 'https://rootly.com/webhooks/incoming/alertmanager_webhooks'
        send_resolved: true
        http_config:
          authorization:
            type: Bearer
            credentials: <token>

# Proposed (native)
receivers:
  - name: rootly
    rootly_configs:
      - url: 'https://rootly.com/webhooks/incoming/alertmanager_webhooks'
        rootly_token: <token>

2. Secret management via file-based fields

A native integration enables rootly_token_file and url_file fields, allowing users to load secrets from files — useful for Kubernetes secrets, Vault, and other secret management tools. This is not possible with the generic webhook receiver today.

3. Discoverability and ecosystem visibility

Native integrations appear in Alertmanager's configuration documentation and are discoverable by users browsing available receivers. This helps users who are evaluating incident management tools find Rootly as a supported option alongside PagerDuty, Opsgenie, etc.

4. Community demand

We've received requests from multiple enterprise customers who expect first-class integration with Alertmanager as part of their evaluation criteria for incident management platforms. Having a native receiver reduces friction for adoption.

Implementation

We have a working implementation ready in PR #4975 that follows the established integration pattern:

• RootlyConfig struct with url/url_file, rootly_token/rootly_token_file, max_alerts, timeout
• Notifier with JSON payload, Bearer token auth, retry on 429/5xx
• Receiver builder wiring and Prometheus metrics registration
• 9 passing test functions, make lint clean, Apache 2.0 headers, DCO sign-offs

The implementation is ~620 lines across 6 files and follows the same conventions as other integrations.

References

• Working PR: #4975
• Rootly: https://rootly.com
• Existing webhook endpoint: POST /webhooks/incoming/alertmanager_webhooks (already in production)

Start by reviewing the linked implementation in PR #4975 and compare its six changed files with existing PagerDuty, Opsgenie, and incident.io integrations. Check the reported nine tests and lint status first. Done means the native Rootly receiver, configuration fields, wiring, metrics, and tests are accepted without duplicating work already underway.