signals/*

signals registry path is used for reporting status, warnings and errors throughout Hantera. It’s used by internal services but is also available for external integrations to write to using the API. Authorization apply as usual.

It’s a common convention for integrations and auxiliary services to report to signals to simplify monitoring of your Hantera environment. Ensure your custom signals do not overlap with system Signals by using unique paths.

Caution

Signals are not persisted. They are meant to report on current issues, and therefor there’s no point in persisting them. This separates the /signal/ path in the registry from all other paths. Do not rely on signals for persistant configuration. This is generally not an issue but should your Hantera environment restart, all signals will be lost.

If you’re using Signals to report errors, make sure to remove the Signal when the problem has been fixed, or replace it with a lesser severity.

Schema

In order for your Signals to be interpreted by other tools, such as Hantera CLI, they should contain certain fields.

Signal Body

severity	’information’ | ‘warning’ | ‘error’ The severity of the signal. Allows users to prioritize and take appropriate action.
properties	map of string to any value (optional) Structured data that will be added to the signal.
code	string A code for tools to recognize the Signal value/state.
messageTemplate	string An explanation of the current Signal status. Preferably in [messagetemplates.org/](https://messagetemplates.org/] format with placeholders referencing properties.