Time handling

Correct handling of measurement time is fundamental to predictable and traceable behavior within the Blockbax Platform. Integrations should ensure correct time ordering and avoid future timestamps to prevent invalid measurements and unintended behavior. This page explains how measurement timestamps are validated and handled when received and at further processing stages, for example when evaluating event rules.

Measurement time

We discourage rewriting history as it can become hard to trace why something led to an event. In order to achieve this we recommend that subjects have a strict increasing time order over measurements being sent to the platform. On a series level we go one step further and enforce this time order. We also disallow sending measurements with a future timestamp as timestamps in the distant future could effectively render a series unusable as history can never be rewritten.

To be specific, a measurement is marked invalid when:

• The timestamp is identical (exact same timestamp in milliseconds) within a series.
• The timestamp is older compared to the latest measurement within a series.
• The timestamp is more than an hour in the future.

These best practices and requirements prevent scenarios where old measurements coming in would be able to invalidate an event. As an event could already led to e-mails and webhook calls, invalidating would become highly impractical and hard to follow.

The following example of messages describes how this works in practice:

Important to note is that in the example each measurement is sent as a separate message. Better is to send measurements in batches per subject. Within a single message the platform fixes the sorting for you. In this way, when you batch the measurements of all metrics for each subject and one or multiple timestamps, you are able to achieve strict increasing time order per subject. In the example this would mean that at least the first and the fourth message would be batched in the same message.

When using calculated metrics these same validations also apply for the resulting measurements.

Event time

Event triggers follow the same forward-only time principle. Each trigger maintains its own internal notion of time. As measurements arrive, conditions are evaluated based on the latest available data. Once evaluated, results cannot be changed retroactively, as time does not move backward. See event trigger timing settings for more details.