# What patterns of logs or warnings should an automated bridge promote to structured faults in ROS 2?

**URL:** <https://discourse.openrobotics.org/t/what-patterns-of-logs-or-warnings-should-an-automated-bridge-promote-to-structured-faults-in-ros-2/54865>\
**Category:** ROS General\
**Tags:** ros2, diagnostics\
**Created:** [May 15, 2026, 10:04am UTC](https://discourse.openrobotics.org/t/what-patterns-of-logs-or-warnings-should-an-automated-bridge-promote-to-structured-faults-in-ros-2/54865 "2026-05-15T10:04:09Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Michal\_Faferek](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/michal_faferek/32/31614_2.png) [@Michal\_Faferek](https://discourse.openrobotics.org/u/Michal_Faferek)\
**Post date:** [May 15, 2026, 10:04am UTC](https://discourse.openrobotics.org/t/what-patterns-of-logs-or-warnings-should-an-automated-bridge-promote-to-structured-faults-in-ros-2/54865/1 "2026-05-15T10:04:09Z")

</div>

We have been working on `ros2_medkit`, an Apache 2.0 fault aggregation gateway for ROS 2 that follows the SOVD model (ISO 17978-3). All of it lives in [GitHub - selfpatch/ros2\_medkit: ros2\_medkit - diagnostics gateway for ROS 2 robots. Faults, live data, operations, scripts, locking, triggers, and OTA updates via REST API. No SSH, no custom tooling. · GitHub](https://github.com/selfpatch/ros2_medkit)

 ![discoursediagram](https://us1.discourse-cdn.com/flex022/uploads/ros/original/3X/a/2/a2a349465bf7f4c5ac388286be01c124b1b73767.png)

Two integration paths today:

1. **`/diagnostics` topic** - drop-in, no code changes on the publisher side. Works for any package already using `diagnostic_updater`.

2. **Native `FaultReporter` instrumentation** - each failure surface emits a structured fault code directly. We tried this on a manymove fork to see how invasive it is to add per-action-node fault reporting. PR is here for reference: [Feat/medkit integration by mfaferek93 · Pull Request #1 · selfpatch/manymove · GitHub](http://github.com/selfpatch/manymove/pull/1) - the integration itself was small (one mixin + a fault-codes header), but that fork is a fairly clean codebase. Most production stacks have a much messier `RCLCPP_ERROR` / `RCLCPP_WARN` history that nobody is going to retroactively convert.

Native `FaultReporter` is the right answer when you control the codebase end-to-end - structured codes from day zero, lowest friction long-term. The painful case is the long tail of existing ROS 2 packages that already work fine and never emitted `/diagnostics`. For those, the drop-in bridge has nothing to subscribe to, and asking maintainers to instrument every node won’t happen. If the goal is to make structured diagnostics adoptable across the ecosystem, plug-and-play needs to mean more than “use `/diagnostics`”.

That gap is what we want to validate with you.

We are considering a third path: a **logs-to-faults bridge** that watches `/rosout` (or arbitrary log streams) and promotes selected patterns to structured fault events, with configurable rules (severity mapping, dedup, rate limiting). Goal: a team can adopt structured diagnostics without touching their existing code. If it works out, it ships in the same open repo as the rest of medkit.

Three questions where your experience would help more than ours:

- What log patterns in your stack would you actually want auto-promoted to structured faults? (specific examples \> taxonomies)

- What blocks your team from using `/diagnostics` more widely today?

- For a logs-to-faults bridge to be useful and not noisy, what would have to be true? (rules engine, allowlist-only, ML, something else?)

Curious what others have tried, especially on the failure-modes side.

_Poll ([view on site](https://discourse.openrobotics.org/t/what-patterns-of-logs-or-warnings-should-an-automated-bridge-promote-to-structured-faults-in-ros-2/54865/1))_

---

<div class="post-metadata">

**Author:** ![Timple](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/timple/32/4891_2.png) [@Timple](https://discourse.openrobotics.org/u/Timple)\
**Post date:** [May 15, 2026, 1:20pm UTC](https://discourse.openrobotics.org/t/what-patterns-of-logs-or-warnings-should-an-automated-bridge-promote-to-structured-faults-in-ros-2/54865/2 "2026-05-15T13:20:38Z")

</div>

I like how you try to cope with the current state of nodes instead of enforcing code changes on nodes. Such a ‘translation’ approach certainly has it’s place.

We have a year old PR on the diagnostic aggregator open:

> <https://github.com/ros/diagnostics/pull/506>
>
> Going from:
> \> Report stale as errors unless all stale
> 
> to:
> \> If one STALE an…d no ERROR, report STALE
> 
> As a bonus, the message that caused the degradation of the diagnostics is added to the toplevel state. This is useful for reporting mechanisms such as error logs.

It publishes the reason for a degradation in diagnostics.

Such a mechanism is very convenient for an immediate report instead of an analysis in hindsight. Think of displaying it on a remote control for the operator.

It immediately points someone into the right direction, so something like this would be valuable as well.

---

<div class="post-metadata">

**Author:** ![bburda](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/bburda/32/31121_2.png) [@bburda](https://discourse.openrobotics.org/u/bburda)\
**Post date:** [May 15, 2026, 2:00pm UTC](https://discourse.openrobotics.org/t/what-patterns-of-logs-or-warnings-should-an-automated-bridge-promote-to-structured-faults-in-ros-2/54865/3 "2026-05-15T14:00:09Z")

</div>

Oh wow, did not know about PR 506 - and a year open is rough. Glad we are not the only ones bumping into this 😅. The input side of medkit is basically a matcher: log lines and warning patterns go in, structured events come out (category, severity, source, cause). The SOVD-specific stuff lives downstream of that, so the matcher itself is generic. Feels like something that could just as well live in `ros/diagnostics` if there is interest - we are going to build it either way because we need it, but happy to design it with reuse in mind from day one.

---

<div class="post-metadata">

**Author:** ![Michal\_Faferek](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/michal_faferek/32/31614_2.png) [@Michal\_Faferek](https://discourse.openrobotics.org/u/Michal_Faferek)\
**Post date:** [May 15, 2026, 2:01pm UTC](https://discourse.openrobotics.org/t/what-patterns-of-logs-or-warnings-should-an-automated-bridge-promote-to-structured-faults-in-ros-2/54865/4 "2026-05-15T14:01:20Z")

</div>

happy to review the PR from a consumer angle if it helps move it along 😅

---

<div class="post-metadata">

**Author:** ![gbiggs](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/gbiggs/32/30361_2.png) [@gbiggs](https://discourse.openrobotics.org/u/gbiggs)\
**Post date:** [May 17, 2026, 11:11pm UTC](https://discourse.openrobotics.org/t/what-patterns-of-logs-or-warnings-should-an-automated-bridge-promote-to-structured-faults-in-ros-2/54865/5 "2026-05-17T23:11:31Z")

</div>

Please do. **Anyone can review any PR** , and having community members review each other’s PRs reduces the load on the maintainers, meaning that all PRs will get merged faster.

---

<div class="post-metadata">

**Author:** ![Michal\_Faferek](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/michal_faferek/32/31614_2.png) [@Michal\_Faferek](https://discourse.openrobotics.org/u/Michal_Faferek)\
**Post date:** [May 19, 2026, 4:47pm UTC](https://discourse.openrobotics.org/t/what-patterns-of-logs-or-warnings-should-an-automated-bridge-promote-to-structured-faults-in-ros-2/54865/6 "2026-05-19T16:47:15Z")

</div>

@Timple done, comments left on [Feature/report stale if one stale by Timple · Pull Request #506 · ros/diagnostics · GitHub](https://github.com/ros/diagnostics/pull/506) . The “why is this stale” bit is exactly the kind of signal that makes downstream consumption easier; if `/diagnostics` carried degradation reasons as first-class fields, the matcher @bburda mentioned would have less guesswork to do.

Still keen to hear what log patterns from other people’s stacks would be worth auto-promoting 🙏