How to Set Up Custom Alerts When Your Data Changes

You find out a number changed three days after it mattered. A support queue grew, an export stopped updating, or a status field flipped, and nobody saw it because the only way to know was to open the dashboard and look.

You may already have tried the built-in alert feature in the tool that holds the data. It offers a few fixed conditions and a couple of delivery options, and your actual rule does not fit any of them. This post shows how to define your own rule, run it on a schedule and get the message where you will see it.

The short answer

A custom data-change alert has three parts: a trigger (the exact condition that counts as a change), a check interval (how often the data is read) and a channel (where the message goes). Write each one down in a sentence, then build a small script that reads the data, compares it to the last value it saw, and sends a message only when the rule is met. Run it on a schedule on a computer or server you control, and test it against data you already know the answer for.

Step 1: Define the trigger

Most alert setups fail here, because “tell me when it changes” is not a rule. Data changes constantly. You need a condition that is true or false.

Good triggers are specific:

  • A value crosses a threshold (queue size goes above an illustrative 100).
  • A value moves by more than a set amount since the last check.
  • A field changes from one state to another (from “ok” to “failed”).
  • A row or file appears that was not there before.
  • Something that should change has not changed for a set period (a “no news” alert).

Decide whether you want the alert on every check where the condition is true, or only on the moment it first becomes true. The second is almost always better. An alert that repeats every check while a value sits above the line trains you to ignore it.

Write the trigger as one sentence: “Alert me once when the open ticket count goes from 100 or below to above 100, and again when it drops back.” If you cannot write it that plainly, the build will be vague too.

Step 2: Choose the check interval

The interval is a tradeoff between how fast you hear and how hard you hit the source.

Ask how long a delay you can live with. If a late alert costs you nothing for an hour, checking every illustrative 15 minutes is more than enough, and checking every minute only adds load and noise. If the data comes from someone else’s website or service, frequent checks can also break their rules or get you blocked. Follow the target site’s terms and the law, and prefer an official export or API over reading web pages when one exists.

Also match the interval to how often the data itself updates. If a report refreshes once a night, checking it every few minutes finds nothing new.

A practical approach is to start slow, watch a few days of results, and tighten the interval only if the delay hurts.

Step 3: Choose the channel

The channel is where the alert lands, and it decides whether anyone acts on it. Common options are email, a chat message through a webhook, a text message through a messaging service, or a line written to a log file that another tool reads.

Pick the one you already look at without being prompted. For most small teams that is email or a shared chat channel. Keep the message short and self-contained, and include:

  1. What changed (the name of the value).
  2. The old value and the new value.
  3. When it was detected.
  4. A link or path to where to look next.

“Queue size went from 94 to 112 at 14:05. Open the support dashboard” is an alert someone can act on. “Threshold exceeded” is not.

Keep any webhook address or password in a config file or environment variable, never inside the script itself, and never paste it into a shared document.

Why built-in alerts run out of options

Built-in alerts are a good first stop, and you should try them before building anything. They are quick to turn on and need no maintenance. They run out of room in a few predictable places:

  • Fixed conditions. You get “above”, “below” or “equal to”, but not “changed by more than a quarter compared with the same hour yesterday”.
  • One source only. The rule can only look at data inside that tool, not compare it with a spreadsheet or another system.
  • Limited channels. Email may be the only option, or the chat integration may not fit your setup.
  • No state. Many cannot remember that they already alerted you, so they either repeat or miss the recovery.
  • Per-seat or per-rule limits. Plans often cap how many alerts you can create.

When two or three of these apply to the same rule, a small custom script is usually simpler than working around the tool.

A small working example

Here is a minimal Python check. It reads one number from a JSON endpoint, compares it to the value saved on the last run, and prints an alert only when the value crosses an illustrative limit of 100 for the first time. Swap the print line for your email or webhook call.

import json
import pathlib
import urllib.request

URL = "https://example.com/api/queue-size"  # your data source
STATE = pathlib.Path("last_value.txt")
LIMIT = 100  # your rule

def fetch():
    with urllib.request.urlopen(URL, timeout=10) as r:
        return json.load(r)["count"]

value = fetch()
last = int(STATE.read_text()) if STATE.exists() else None
STATE.write_text(str(value))

if value > LIMIT and (last is None or last <= LIMIT):
    print(f"ALERT: count crossed {LIMIT}, now {value}")

Run it on a schedule with cron on Linux or macOS, or Task Scheduler on Windows.

To check it worked, do not wait for a real event. Temporarily set the limit just below the current value and confirm one alert arrives. Run it again and confirm no second alert. Then set the limit back above the value, run it, and set it low again to confirm the alert returns. That covers the three behaviors that matter: it fires, it does not repeat, and it re-arms.

Then add the parts that make it dependable: a try/except so a failed fetch sends a “the check itself failed” message rather than silence, and a log line on every run.

When to do it yourself and when to hand it off

Do it yourself when the rule is simple, the data source offers a clean API or export, and you are comfortable with a short script and a scheduler. The example above is close to a complete solution for a single value. A weekend of tinkering is a fair price for something you will understand and can change.

Doing it yourself gets harder when:

  • You have several rules across several sources, each needing state tracking.
  • The data comes from a page or file format that changes shape and needs careful parsing.
  • You need retries, rate limiting, a log, and a clear message when the check itself breaks.
  • You do not have the time to write, test and document it, or nobody on the team will maintain it.

At that point a custom build is a reasonable route. Custom Builds delivers code you run yourself, to your spec, at a fixed price agreed in writing before work starts, from $300 per project. You describe the trigger, interval and channel by email, and you get either a fixed quote with a delivery date or a clear “not a fit” within 24 hours. There are no calls or meetings. Projects that would break a platform’s terms or the law are not taken on, and neither is ongoing hosting or management.

The takeaway

An alert is only as good as its rule. Write the trigger as a true-or-false sentence, set the interval to match how fast the data moves and how long a delay you can tolerate, and send the message to a channel you already watch. Test it against known data before you trust it.

If you would rather have this built for you: Custom Builds makes alert systems, scripts and data pipelines to your spec, delivered in under 7 days for qualifying projects as one zip file with source code, a README, an install guide, a usage guide, a one-command setup script and a sample config. It runs on your own computer or server, and you own the setup and keys. Request a build at automatehive.net/custombuilds.

Custom Builds delivers software only. Nothing on this page is financial, investment or betting advice.