On large trend/history tables, timescaledb compression can take quite a long time. During compression, the table is "locked" and data cannot be written to it (because not only the "chunk", but the entire hypertable is locked). This may cause "holes" in the data, as well as a lack of any data (because all syncers will want to write something to the currently compressed table and will "hang" because the table is locked).
One possible solution to this problem is to force compression during times of lower traffic (e.g. at night or on the weekend). When we "manually" change compression settings from the DB level, each change from the GUI level undoes the manual changes.
I suggest changing the "add_compression_policy" query in the "history_compress.c" file to something similar:

SELECT add_compression_policy(
    'trends',
    compress_after => integer '871200',
    schedule_interval => INTERVAL '1 day',
    initial_start => '2000-01-01 00:00:00+00'::TIMESTAMPTZ
);

And adding additional checkboxes in the GUI: "Administration -> Housekeeping -> History and trends compression" to additionally control the "initial_start" (this is so important for us) and "schedule_interval" (optional) parameters.