What to know before relying on Signals in an Ovok app: which readings are sent, retries and gaps, episodes, annotation limits and access.

Which readings reach Signals

Your project needs its own Signals tenant. On the shared tenant, both settings stay off and turning one on answers 409 SETTING_NOT_AVAILABLE.
Only created Observations. SIGNALS_SEND_AUTO sends an Observation when it is created through the FHIR API. Updating one sends nothing. To correct a reading, create a new Observation.
Some are skipped. An Observation whose subject is not a Patient, one with status entered-in-error or cancelled, and one carrying an ovok-event-id or Signals identifier are not sent.
Ingest is separate. Readings from Data Ingestion are sent by the ingest path, whatever SIGNALS_SEND_AUTO says. Turning the setting off does not stop them.
The first reading enrols the patient. You need $enable-signals only to enrol a patient before any reading, for example to set their thresholds first.
The same reading twice is judged once. Signals ignores a reading it already has within an hour.

Retries and gaps

About 34 minutes of retries. If Ovok or Signals is down, the notification for a new Observation is retried for about 34 minutes. A longer outage loses that reading for Signals. The Observation stays in FHIR; it is not sent again later, and nothing replays it.
Deleting the Subscription stops sending. The Subscription tagged signals-send-auto is Ovok's. If it is deleted through the FHIR API, sending stops for the project; save SIGNALS_SEND_AUTO again to re-create it.
No backfill. SIGNALS_ANNOTATE_OBSERVATIONS writes alerts raised after it is turned on, not earlier ones.

Episodes need episodicAlerts. With it off for your tenant, Signals records no episodes: you get DetectedIssues but no Flags, and episode feeds stay empty. Turning it off empties them.
Coarse grading. severity is always moderate, and interpretation is only H, L or A. Signals' bands have no critical limits, so there is no HH or LL.
Not every alert has a reading. A reading Ovok did not keep in FHIR, such as a realtime tick from a device, gives a DetectedIssue with no implicated. Note, empty-reading and inactivity alerts never annotate an Observation.
Events can arrive out of order. Ovok merges them by Signals' alert version, so the stored DetectedIssue is always the newest. implicated and mitigation only grow, and a closed Flag never reopens.
Old Flags. Projects that used Ovok before 2026-10-15 can hold Flags from an older Ovok marker. Search episodes with identifier=https://signals.actimi.com/episode|.
Patients created through the standalone API. Annotations cover every alert of your tenant and name the patient as Patient/<refId>. For a patient you create through the standalone API, use its FHIR Patient id as refId, or its DetectedIssue points at no Patient. A project that uses only the standalone API should switch both settings off.

Don't write DetectedIssue or Flag yourself. Ovok owns them, and a raw write never reaches Signals. Acknowledge an alert through the Slim notification routes or the standalone acknowledge route; the DetectedIssue then gains an Acknowledged mitigation.
Thresholds live in Signals. Change them through the Slim threshold routes. Editing a Goal or CarePlan directly never reaches Signals.
Grant read on DetectedIssue and Flag. Roles that should see alerts need both in their access policy. Integration applications have them; Manager and Submitter applications hold Signals capabilities only.
$enable-signals needs two grants. The caller needs signals_config:update and Patient update. Project admins have both; a new Manager or integration application has only one.