Skip to main content
PriceSignal’s alert rules system allows you to define sophisticated conditions that trigger notifications when cryptocurrency prices meet your criteria. Create rules based on absolute prices, percentage changes, price action, crossovers, and technical indicators.

​
Rule Structure

Each price rule consists of:
  • Name: Descriptive identifier for the rule
  • Description: Detailed explanation of what the rule monitors
  • Instrument: The cryptocurrency pair to track
  • Conditions: One or more conditions that must be met
  • Notification Channel: How you’ll be alerted when the rule triggers
  • Status: Whether the rule is currently active

​
Create a Price Rule

mutation CreatePriceRule($input: PriceRuleInput!) {
  createPriceRule(input: $input) {
    id
    name
    description
    isEnabled
    instrument {
      symbol
      name
    }
    conditions {
      nodes {
        conditionType
        value
        additionalValues
      }
    }
    notificationChannel
    createdAt
  }
}
Variables: 
{
  "input": {
    "name": "BTC Price Alert",
    "description": "Alert when Bitcoin exceeds $70,000",
    "instrumentId": "550e8400-e29b-41d4-a716-446655440000",
    "isEnabled": true,
    "notificationChannel": "TELEGRAM",
    "conditions": [
      {
        "conditionType": "PRICE",
        "value": 70000,
        "additionalValues": "{\"direction\": \"above\"}"
      }
    ]
  }
}
Rules are evaluated in real-time as price updates are received. Once a rule triggers, it won’t trigger again until the conditions are reset.

​
Condition Types

PriceSignal supports five powerful condition types extracted from the codebase:

​
1. PRICE

Trigger when the price crosses a specific absolute value. 
{
  "conditionType": "PRICE",
  "value": 50000,
  "additionalValues": "{\"direction\": \"above\"}"
}
Triggers when price rises above $50,000

​
2. PRICE_PERCENTAGE

Trigger based on percentage change from a reference point. 
{
  "conditionType": "PRICE_PERCENTAGE",
  "value": 5.0,
  "additionalValues": "{\"direction\": \"increase\", \"timeframe\": \"24h\"}"
}
This triggers when price increases by 5% within 24 hours.
The percentage change is calculated from the price at the start of the specified timeframe:
percentage_change = ((current_price - reference_price) / reference_price) * 100
  • Reference Price: Price at the start of the timeframe
  • Direction: Can be “increase” or “decrease”
  • Timeframe: Supported values: “1h”, “4h”, “24h”, “7d”

​
3. PRICE_ACTION

Detect specific price movement patterns. 
{
  "conditionType": "PRICE_ACTION",
  "value": 0,
  "additionalValues": "{\"pattern\": \"higher_high\", \"lookback\": 10}"
}
Supported Patterns:
  • higher_high: Price makes a new high compared to the lookback period
  • lower_low: Price makes a new low compared to the lookback period
  • breakout: Price breaks above a consolidation range
  • breakdown: Price breaks below a consolidation range

​
4. PRICE_CROSSOVER

Trigger when price crosses a moving average or when two moving averages cross. 
{
  "conditionType": "PRICE_CROSSOVER",
  "value": 0,
  "additionalValues": "{\"type\": \"price_ma\", \"ma_type\": \"SMA\", \"period\": 50, \"direction\": \"above\"}"
}
Price crosses above the 50-period Simple Moving Average

​
5. TECHNICAL_INDICATOR

Trigger based on technical indicator values (RSI, SMA, EMA). 
{
  "conditionType": "TECHNICAL_INDICATOR",
  "value": 70,
  "additionalValues": "{\"indicator\": \"RSI\", \"period\": 14, \"comparison\": \"above\"}"
}
See Technical Indicators for complete indicator documentation.
Technical indicator conditions require sufficient historical price data. Ensure the instrument has been tracked for at least the indicator’s period before the rule can trigger.

​
Managing Rules

​
Query Your Rules

query GetMyPriceRules {
  priceRules(first: 20, order: { createdAt: DESC }) {
    nodes {
      id
      name
      description
      isEnabled
      lastTriggeredAt
      lastTriggeredPrice
      instrument {
        symbol
        name
      }
      conditions {
        nodes {
          conditionType
          value
          additionalValues
        }
      }
      notificationChannel
      activationLogs {
        nodes {
          id
          triggeredAt
          price
          priceChange
          priceChangePercentage
        }
      }
    }
    totalCount
  }
}

​
Update a Rule

mutation UpdatePriceRule($input: PriceRuleInput!) {
  updatePriceRule(input: $input) {
    id
    name
    description
    isEnabled
    conditions {
      nodes {
        conditionType
        value
      }
    }
  }
}

​
Toggle Rule Status

mutation ToggleRule($id: ID!) {
  togglePriceRule(id: $id) {
    id
    isEnabled
    name
  }
}
Toggling a rule automatically manages WebSocket subscriptions. Enabling subscribes to price feeds; disabling unsubscribes if no other rules need that instrument.

​
Delete a Rule

mutation DeletePriceRule($id: ID!) {
  deletePriceRule(id: $id) {
    id
    name
  }
}

​
Activation History

Every time a rule triggers, an activation log is created with detailed context: 
query GetRuleHistory($ruleId: ID!) {
  priceRule(id: $ruleId) {
    activationLogs(first: 50, order: { triggeredAt: DESC }) {
      nodes {
        id
        triggeredAt
        price
        priceChange
        priceChangePercentage
        priceRuleSnapshot
      }
      totalCount
    }
  }
}
Activation Log Fields:

triggeredAt

Exact timestamp when the rule was triggered

price

The price that triggered the rule

priceChange

Absolute price change from the previous trigger

priceChangePercentage

Percentage change from the previous trigger

priceRuleSnapshot

Complete snapshot of the rule configuration at trigger time
Rule snapshots preserve the exact configuration when the alert triggered. This is crucial for:
  • Audit Trail: See what conditions were in effect
  • Historical Analysis: Understand past performance even if you’ve modified the rule
  • Compliance: Maintain records of automated trading decisions
  • Debugging: Identify why a rule triggered when you didn’t expect it

​
Best Practices

​
Combine Multiple Conditions

While the current implementation evaluates conditions independently, you can create multiple rules for the same instrument with different notification channels: 
mutation CreateMultiConditionStrategy {
  rule1: createPriceRule(input: {
    name: "BTC Support Alert"
    description: "Alert on support level"
    instrumentId: "..."
    notificationChannel: "TELEGRAM"
    conditions: [{
      conditionType: "PRICE"
      value: 60000
      additionalValues: "{\"direction\": \"below\"}"
    }]
  }) { id }
  
  rule2: createPriceRule(input: {
    name: "BTC Resistance Alert"
    description: "Alert on resistance level"
    instrumentId: "..."
    notificationChannel: "TELEGRAM"
    conditions: [{
      conditionType: "PRICE"
      value: 70000
      additionalValues: "{\"direction\": \"above\"}"
    }]
  }) { id }
}

​
Avoid Alert Fatigue

  • Set meaningful thresholds that represent significant price movements
  • Use percentage-based alerts for volatile assets
  • Monitor activation history to tune your rules
  • Disable rules during low-confidence periods

​
Test Before Deploying

  1. Create a rule with a notification channel you actively monitor
  2. Set conservative thresholds initially
  3. Review activation logs after 24-48 hours
  4. Adjust conditions based on trigger frequency
  5. Enable more aggressive rules once confident
Rules are user-specific. Each user can create their own rules for any instrument, and rules only trigger notifications for the user who created them.

Build docs developers (and LLMs) love

Get started for freeTalk to us