FAQ

Does the automation check the entire time series every time, or only new data?

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.

Is there a way to force an automation to check the entire time series if the job it maps to has already run?

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.

How often will my automation run?

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.

The "Time series evaluation status" settings, with the option to view and edit an evaluation schedule.

What is the difference between time series alerting automations and time series Foundry Rules?

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.

Which Quiver cards are supported in time series alerting logic?

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.

Why did I receive an error about needing a single root object type?

An error that occurred because more than one root object type was used.

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.

An error that occurred because no root object types were used.

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.

Can I apply the same time series alerting template to different objects?

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.

Can I use time series backed by streams?

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.

What happens to an alert that is ongoing when the logic runs?

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.

What happens to historical alerts when the logic changes?

Historical alerts will not be recomputed. After the logic change happens, new events will be identified using the new logic.

What happens to ongoing alerts when the logic changes?

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.

Can I modify the configuration of my evaluation job?

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.

The "Job Configuration" editing pop-up.