An exit signal happens for linked processes. But it’s important to remember:

• The primary intent of an exit signal is to terminate all processes that are linked together - because “the whole” cannot succeed when a “part” is missing.
• Trapping the exit signal transforms it to an EXIT message. Often this is done so that a process can terminate in a graceful manner - e.g. to release precious resources before terminating itself.
• A link is a process relationship that works both ways - either process terminating will result in an exit signal to the other.
• A monitor is a one way process relationship - only the monitoring process will be informed with a DOWN message of the demise of the other - not the other way around.
• Even though a supervisor doesn’t want to be terminated by its children (i.e. the supervisor traps exits), it does want to take down ALL its children if the supervisor unexpectedly goes down. So it makes perfect sense to use links rather than monitors in supervisors.

This way the observer process could avoid invoking the faulty process for a few seconds (if it fails too often) and use other processes (in my problem they are all similar but use different “channels” to send data).

You might want to take a look at circuit breaker implementations:

https://github.com/klarna/circuit_breaker
https://github.com/jlouis/fuse
https://github.com/jvoegele/external_service

At least you can get a notification when the old one dies with Process.monitor/1.

One trick is have an ETS table that is owned by the supervisor, but is managed by the supervised process. So store the observing pids in the ETS table and have the fresh process send notifications to the observing processes about “the change in management”.

See Steve Vinoski: Don’t Lose Your ETS Tables

The observing processes would still have to use monitors if they need to know quickly that the old process has terminated.