feat(crd): add additional integration types (PagerDuty, Teams, Opsgenie, Webhook)

[joelp172]

Summary

Only Slack integrations are supported. UptimeRobot supports many other integration types that users may need.

Current Behaviour

• Only `SlackIntegration` CRD exists
• UptimeRobot API supports: Slack, PagerDuty, Opsgenie, Microsoft Teams, Webhooks, Zapier, Splunk, and more
• Users wanting other integrations must manage them outside the operator

Proposed Approach

Option A: Separate CRDs per integration type

kind: PagerDutyIntegration
kind: TeamsIntegration
kind: WebhookIntegration

Pros: Type-safe, specific validation per integration
Cons: CRD proliferation

Option B: Generic Integration CRD

kind: Integration
spec:
  type: pagerduty
  config:
    serviceKey: "..."

Pros: Single CRD, extensible
Cons: Weaker type safety, complex validation

Recommended: Start with highest-value integrations

1. Webhook (generic, covers many use cases)
2. PagerDuty (common in enterprise)
3. Microsoft Teams (common in enterprise)
4. Opsgenie (common in enterprise)

Acceptance Criteria

• Validate each integration type against real API
• At least Webhook integration implemented
• Consistent pattern with existing SlackIntegration
• Unit and E2E tests per integration type
• Documentation with examples

Phase

P4 — Feature Gaps (Phase 3: Expand)

[andrianvaleanu]

Option B seems like the cleaner path here since UptimeRobot's API schema for alert contacts is actually pretty uniform once you get past the type ID. Managing a dozen nearly identical CRDs for every niche provider usually ends up being a maintenance headache. If you're looking for a simpler way to handle multi-channel status alerts without the CRD overhead, https://pulsetic.com/ handles this natively via a single webhook or API call. Might be worth checking out if the goal is reducing manual config.