Skip to main content

Detecting Data Changes with Alert Rules

You can trigger alerts in JupiterOne when data in your graph has changed! While many alerts focus on the number of results changing, JupiterOne allows you to detect when entities in your environment have been recently updated or created by leveraging timestamp-based queries.

How It Works​

The key to detecting changes in your graph is to:

  1. Write a J1QL query that looks for entities with recent timestamp updates using time-based filters
  2. Configure the alert rule to trigger when these entities appear in the query results

By using DATE.now - [time unit] in your queries, you can identify entities whose lastUpdatedOn (or _createdOn) timestamp falls within a recent time window. When you set the alert rule's trigger condition to activate "when entities that did not exist during the previous rule evaluation appear in the question results", JupiterOne will fire an alert each time an entity's timestamp update makes it "newly" match your query.

Important: This approach detects that something has changed in your environment, but does not tell you exactly what properties were modified. For specific change details, you'll need to check your source system logs.

Important Limitations​

Before implementing data change detection, understand these key limitations:

  • Entity dependency: You need entities that come with timestamp properties like lastUpdatedOn. JupiterOne does not track this information in our metadata - it relies on the source system (like AWS) to provide these timestamps.

  • Timestamp-based detection only: This method can only target timestamp properties (like lastUpdatedOn or _createdOn). You cannot identify when specific individual properties have changed.

  • No property-level change details: The alert will tell you that an entity has changed, but not what changed. To determine which specific properties were updated, you need to check the source system's logs (such as AWS CloudTrail).

  • Source system limitations: Not all integrations or entity types provide reliable timestamp properties. Check your specific integration documentation to confirm timestamp availability.

This is best used for broad change detection across your environment rather than granular property monitoring. For detailed change tracking, combine JupiterOne alerts with your source system's native change logs.

Example Queries​

Detecting recently modified CloudTrail resources:

FIND aws_cloudtrail_resource WITH lastUpdatedOn > DATE.now - 1 hour

Detecting new users created in the last 14 days:

FIND jupiterone_user WITH _createdOn > DATE.now - 14 day

Detecting recently updated data stores:

FIND DataStore WITH lastUpdatedOn > DATE.now - 6 hours

Configuration Tips​

  • Use appropriate time windows: Choose time intervals that align with your alert evaluation frequency. For example, if your rule runs every hour, use a time window slightly larger than 1 hour to avoid missing updates.

  • Leverage entity properties: Most JupiterOne entities have _createdOn and lastUpdatedOn properties that track when the entity was first ingested and last modified.

  • Combine with other filters: You can combine time-based filters with other conditions to create more targeted alerts:

FIND DataStore WITH classification='critical' AND lastUpdatedOn > DATE.now - 2 hours

This approach provides a way to get notifications when changes occur in your environment, enabling you to stay informed about activity across your infrastructure and applications.

Getting Started​

To create a change detection alert for your environment:

  1. Navigate to Alerts and select the Rules tab
  2. Click New Rule
  3. Configure your rule with a time-based J1QL query as shown in the examples above
  4. Set the trigger condition to activate when new entities appear in results
  5. Configure your desired actions (email, Slack, Jira ticket creation, etc.)
  6. Set an appropriate polling interval that aligns with your time window

Remember: This will alert you that something has changed, but you'll need to investigate further to determine exactly what changed.

For more information on creating alert rules, see the main Alerts documentation.

Contents