As mentioned on the overview page, your automation maps to an evaluation job. The first time this job runs, it will attempt to check the entire time series for alerts. From then on, it will only check for alerts on new data. This means that if you add an automation to an existing job, historical data will not be processed. In other words, expanding the scope on an existing automation or creating a new automation that writes to an existing alerting object type will only generate alerts on time series data that comes in after you make this change.
This is not currently possible. Reach out to Palantir Support for assistance if your use case requires running an automation that maps to an existing job on historical data.
As mentioned on the overview page, your automation maps to an evaluation job. By default, the job will run whenever there is new data in the datasets backing the time series used in your alerting logic. However, you can put your automation on a time-based schedule if you prefer.
We expect the runtime and cost of the evaluation of these automations to be lower than Foundry Rules for the majority of workflows because we compute incrementally as the time series data updates. Foundry Rules runs against the full time series every time.
All Quiver cards that are supported in derived series logic are supported in time series alerting logic. View the list of supported cards in our documentation.
If you receive an error for not having a single root object type, you likely used two different objects for comparison. For example, you may have pulled the Inlet pressure
property on Machine 1
and compared it with the Outlet pressure
from Machine 2
instead of comparing two properties on the Machine 1
root object type. To create a time series alerting automation, you will need to start from a single root object instance.
If you receive an error for not having a root object type, your analysis likely started from a sensor object type. For example, you may have pulled and compared the sensor object called Inlet pressure
from the sensor object type instead of pulling the property from the Machine 1
root object type. To create a time series alerting automation, you will need to start from the root object instance.
Review the requirements for setting up a time series alerting automation to learn why time series alerting automations must be generated from the perspective of a root object.
Yes. The logic and conditions are templatized so results can be identified from the perspective of any object with the same object type. By default, the alerting logic will be applied to all objects within the starting root object type. Learn more about applying a filter to limit the scope of your automation.
Yes. However, the automations will not run directly on top of the streaming data but rather on top of the archive dataset. This incurs at least 10 extra minutes of latency since archive jobs run every 10 minutes.
An alert that is ongoing will be generated in the output object type. You can tell that it is ongoing by the fact that its end timestamp is empty.
Historical alerts will not be recomputed. After the logic change happens, new events will be identified using the new logic.
If the new alert logic for a given root object indicates that that object is in a normal state, the alert will be resolved. If the new alert logic indicates that that object is in an alerting state, the alert will remain open.
As mentioned on the overview page, your automation maps to an evaluation job. You can modify the job configuration by navigating to the Overview page of your saved automation and selecting View Configuration in the Time series evaluation status section. Select Spark profiles or modify specific time series alerting default behavior in the Job Configuration pop-up. Note that any job configurations will be applied to the whole job, which could include several automations.