Fallback or failure notification

[TheKalpit]

💡 The Idea

It would be great to have a feature which can ideally let a user define a fallback notification service, i.e. attempt to send a notification to serviceA, but if it fails send to serviceB.
or if that's too complicated to implement, at least a "global catch-all" which sends an alert if any notification fails.

Is it something already possible?

[caronc]

I would have to think about that; i wouldn't say its an impossible objective, but wouldn't it be easier to just notify both end points?

also if one endpoint is failing, maybe there is a bug I need to look into?

[TheKalpit]

@caronc Not really a bug. Here's a possible scenario - you set up a notification service (via API keys or whatever), and the API keys got invalidated in future (manually or auto-expiry) or could be an error in the notification service itself. It'd be a useful feature to know when that notification failed.

[egvimo]

I would also appreciate this feature. Other possible scenarios: network issues, rate limits, or provider downtime.

It would be helpful to have a configuration option that defines fallback notification channels or a retry mechanism.

Proposal

• Fallback via tags:
  Allow users to specify a tag (or multiple tags) that should be used if a primary notification fails. This makes it easy to define alternative delivery paths (e.g., if Slack is down, fall back to email).

• Retry option (minimal viable implementation):
  Allow specifying a retry count and/or backoff time before failing over completely. This would cover transient issues without requiring a full fallback chain.

Example config idea:

urls:
  - gchat://workspace/room1: # primary
      - tag: someTag
  - mailto://user:pass@server.com?to=me@example.com: # fallback
      - tag: fallback

# Error handling config
error:
  tag: fallback         # if primary fails, try services tagged "fallback"
  retry:
    attempts: 3         # retry 3 times
    delay: 10s          # wait 10 seconds between retries