Rules

There are two ways to set the limit.

Own threshold or norm for each hour

Why a fixed threshold often fails

On-chain activity rises and falls through the day. A threshold set for daytime traffic stays silent at night, when a drop by half is already a problem. A threshold set for night traffic fires every morning on normal growth. Set once, it also goes stale: in a quarter the norm is different, the rule fires on noise, and people mute it.

How the norm works

The norm is the usual value of the metric at this hour. SmartAlert takes the values of the same hour over the previous days and uses their median. The rule fires when the current value is further from the median than a set number of typical deviations. The typical deviation is the median of the deviations from that median.

A median is used instead of an average because the history window often contains a past incident. One outlier barely moves a median, so the rule keeps seeing the next incident.

On a flat series the deviation is zero. To avoid firing on every event, the minimum deviation is the larger of 1 and 10% of the median.

The norm is calculated for each series separately. The norm is not stored: it is recalculated on every check, so it follows the metric.

Settings:

• Compare with: the same hour on previous days; the same hour and weekday; the previous equal period. Some options need a paid plan; the form marks them Pro.
• Fire when the value is: above the norm, below the norm, or either way.
• Sensitivity: high, medium or low. Medium is the default. High fires at a smaller deviation, low at a larger one.

When the norm is not available

The norm needs history. Until there is enough, the app says "Norm unavailable" and shows the date it will appear. It does not fill the gap with a made-up number. The rule is saved, but it is not evaluated on that series until the norm appears.

A series that first appeared yesterday has no norm yet. Other series of the same rule are evaluated as usual.

Own thresholds by hour

You can set your own limit for a single hour on the norm chart.

1. Open the rule with the norm. Click an hour on the chart.
2. In the popover, set above and/or below.
3. Save. The hour is marked on the chart.

How it works:

• Your limit replaces the norm limit in that hour. It can be stricter or looser. A looser night limit is allowed.
• Hours you did not set follow the norm. The side you did not set also follows the norm.
• "Below" must not be above "above".
• Hours are stored in UTC. The app shows and accepts hours in your time zone, the same as everywhere else. If the time zone changes or clocks shift, the entries stay on their UTC hour and move by one hour on screen.
• Hourly thresholds need a 1-hour window. With a longer window the control is off, and the app says which window to choose.
• In an hour where the norm is not available yet, your limit works at once.
• To return an hour to the norm, open it and choose Back to norm. The list under the chart has a "back to norm everywhere" link.

Check on history

When you create or edit a rule, SmartAlert runs it over the history available to your project. This is also called a backtest. You see:

• the chart: the metric, the norm band or your threshold, and marks where the rule would have fired;
• the number of firings that would have happened over the period.

This is what would have happened, not a forecast. "Would have fired 3 times in 30 days" says nothing about the next 30 days.

The check uses the same code as the live rule, so the preview and the real behaviour match.

The period is limited by your history depth: 7 days on Free, 90 on Pro, 180 on Business, 365 on Enterprise. In the first 14 days of a project it is 90 days.

Drag the threshold on the chart

On the rule page you can drag the threshold line with a mouse, a finger or the arrow keys. When you let go, SmartAlert runs the rule on history again with the new threshold and says under the chart: "With threshold 45,000 it would have fired 1 time · now 4 times". Save threshold changes the rule, Reset keeps it as it was.

Only a single line drags: "above" or "below" a threshold. Range rules, norm rules and balance change rules have no handle.

Threshold fit

Most people can't say what number to put in a threshold. Most can say how often they accept being woken up.

In the rule form, set how many firings you accept and over what period, for example "no more than 2 per week". SmartAlert finds the threshold, or the sensitivity for a norm rule, that gives no more firings than that on the chosen period of history. You see the result on the same chart and accept it in one step.

Threshold fit also works on a running rule. You get a suggestion to change the threshold.

The fit is based on history. If the contract behaves differently later, the real number of firings can differ.

Firings on the chart

Under the chart on the rule page you see what actually happened in the chosen period. Each firing lies on the chart as a band from start to resolve, and below the chart as a row:

• when it fired and how long it lasted, or "ongoing";
• where the notification went and whether it arrived: "On-call delivered", "not delivered", "suppressed";
• what you decided: accepted, dismissed or no decision.

The band colour follows the decision: red is accepted or still ongoing, grey is dismissed, yellow is no decision. A row opens the firing's page.

With at least three decisions and half of them dismissed, the list says the threshold is noisy: the rule wakes you more often than it should. Raise the threshold by dragging it or with threshold fit.

The rows show the 20 latest firings, the rest are in the alert history.

How long the balance lasts

On the address page each token shows how many days the balance lasts at the current spending rate: "Lasts ~2.5 days · spending over 24 h: 0.12 ETH a day". You see the keeper wallet running out of gas in advance, not after it ran out.

How it is calculated. Spending is the sum of every drop of the balance within the window, between neighbouring samples. Top-ups are not subtracted: a wallet topped up yesterday spends just as much. Spending over the window is scaled to a day, and the current balance is divided by it. The forecast is linear: spending is assumed to stay the same. On the address chart the forecast is a dotted line from the last sample to zero, and below the chart is the time the balance reaches zero (UTC).

Windows. The address page uses 24 hours. In a rule you pick: 6 hours, 24 hours or 3 days. A short window notices rising spending sooner, a long one is calmer about one-off spends.

When there is no forecast.

• Spending not visible. The balance never dropped within the window: nothing is spent, or the wallet is only topped up. The rule does not fire.
• Calculating. Less history than a quarter of the window: the address was just added or collection stopped. For a 24-hour window that is 6 hours of history. While there is no forecast, the rule follows its "No data" policy.
• More than 365 days. Spending is so small that an exact number means nothing. The rule does not fire.

Rule. Type "How many days the balance lasts": condition "less than" or "at most", threshold in days, fractions allowed, 0.5 is half a day. Notification: "Runway 2.5 days (condition < 3 d)", for "at most" it is "≤ 3 d", and a line "Burn: 0.12 ETH/day over 24 h, balance 0.3 ETH". Available on every plan, Free included.

Transfer above an amount in $

A threshold on a single ERC-20 token transfer can be set in dollars: "Withdrawal above $50,000 in one transfer". The rule watches the Transfer event and fires when the largest transfer in the window is worth more than the threshold. You can add a filter, for example only transfers from the treasury address.

How it is computed. The transfer amount in tokens × the token price at the moment of the transfer: the latest price no later than the transfer block. Not the price at check time and not a sum over the window. The price comes from Chainlink, or from CoinGecko when Chainlink has none.

When there is no price. If the price is stale or missing, the transfer has no $ amount and is not counted. A window without transfers is not an alert: silence is normal for a token. If the window has transfers but none of them has a price, the rule follows its "No data" policy. SmartAlert starts reading the token's prices once the rule is enabled: earlier transfers have no price, and the check on history leaves them out with "3 transfers without a price not counted".

Notification.

Value: Transfer 52,300 USDC ($52,296) > $50,000
52,300 USDC × $0.99992, Chainlink, 12:03 UTC
Transaction: 0xab…12

Plan. A $ threshold is Pro and above, a threshold in tokens is on all plans. After a downgrade the rule keeps working; you can edit it only on Pro.

Two conditions: AND / OR

A rule can have a second condition. The link decides when the rule fires:

• AND — both hold. For example, "balance below 1 ETH AND no top-up for 1 hour": the wallet is draining and nobody refills it.
• OR — at least one holds.

The second condition reads the same thing as the first: the same address balance or the same contract. For a balance: "balance below", "balance above" or "no top-up for a window". For events: a condition on events of the same contract or "no event for a window". The absence window is 15 minutes, 1 hour, 6 hours or 24 hours. A top-up is a balance rise between two neighbouring samples.

Two conditions at most. Grouping is not available in a two-condition rule. Conditions that can never hold together (for example, "balance rose" AND "no top-up" over the same time) cannot be saved.

The check on history shows the firings of the pair and, separately, how many times each condition held. Threshold fit works for single-condition rules only.

Under the value, the notification shows a conditions block: "Both conditions met (AND)" with ✓ on each, or "One of the conditions met (OR)" with ✓ and ✗. The webhook carries the alert.conditions field.

Plan. Pro and above. If the plan is downgraded, a two-condition rule keeps working as before. You can save it with two conditions only on Pro; removing the second condition is always allowed.

Escalation

If nobody accepts a firing within 5, 10, 15, 30 or 60 minutes, it goes to a second channel, for example the on-call PagerDuty. One step: the time and the channel. The escalation channel must differ from the rule's main channels.

The timer stops on:

• I'm on it. The button on the firing page. It is not a verdict: you can stop the escalation before you know whether the firing is real.
• A verdict: confirmed or false positive.
• The firing resolved.
• The rule changed. Disabled, deleted, or the step was removed.

On time, the escalation channel gets the same notification with the first line "Escalated: not accepted in 10 min". When the firing resolves, the channel gets "back to normal" too, and the PagerDuty incident closes. If the channel is disabled by then, the delivery log shows it as skipped.

The firing page shows when the escalation fires and how it ended: "Escalated to PagerDuty at 14:12", "Taken — escalation cancelled" after "I'm on it", or "Accepted — escalation cancelled" after a verdict.

Plan. Pro and above. After a downgrade the step stays in the rule but does not run. After an upgrade the escalation works again.

Noise control

These limits reduce notifications, not firings. The firing history stays complete.

• While a series is in alert, new notifications for it are not created.
• After a notification, the same series does not notify again until the rule's cooldown passes.
• When the daily notification limit is reached (50 on Free, 1000 on Pro, 5000 on Business), further deliveries are marked "skipped".

No data

Each rule has a policy for when there is no data:

• Treat as normal. For rare events.
• Treat as alert. Silence is the problem. The rule works as a dead-man switch: the contract stopped working.
• Separate state. A "no data" notification, kept apart from ordinary firings.