Where to start
If you are setting up alerting from scratch, these four cover most real incidents:- An uptime monitor on a health-check endpoint.
- An error rate trigger on your
webnamespace. - A p95 response time trigger on user-facing traffic.
- Check-ins for scheduled jobs.
Is the app reachable?
Use: Uptime monitoring An external check that your endpoint still responds. It is the only alert that still works when your app cannot send anything to AppSignal at all, which is why most teams set it up first.
AppSignal requests the URL every minute from four regions and reports a failure when the response is not in the
2xx range or does not arrive within 30 seconds.
Each region is tracked separately, so a monitor opens one alert per failing region. A genuine outage opens up to four alerts, and a network problem between one region and your endpoint opens one alert while your application is fine. This is the main reason to set a warm-up on uptime monitors: a single-region failure that resolves within a minute does not send a notification.
An uptime monitor also produces metrics tagged by region and monitor name, so you can add anomaly detection triggers on response time per region if you need finer alerting than up or down.
SSL certificate expiration monitoring is available as an AppSignal Labs feature. Once enabled, you turn it on for an individual https:// monitor rather than building a trigger by hand, and AppSignal notifies you when the certificate has fewer than 14 days remaining, using the same notifiers as the monitor. Certificate expiry is a slow-moving problem, so route it to email or chat rather than on-call.
Are users hitting errors?
Use: An anomaly detection trigger on error rate, scoped to a namespace Error rate is the fastest indicator that users are experiencing errors, and it stays meaningful as traffic changes.
The suggested trigger in AppSignal starts at 20%, which is deliberately conservative so a new app does not immediately produce alerts. Lower it once you know your baseline.
Create a separate, more forgiving trigger for
background. Job failures usually retry, so they rarely justify the same urgency as failing web requests.
Running two error rate triggers at different thresholds works well, as long as each one has a different destination. A trigger at your normal degradation threshold goes to chat, and a second one at a much higher threshold, such as 50%, means there is a serious issue and should notify on-call. Two thresholds pointing at the same notifier only double the notifications.
When to use error count instead
Error count crosses a fixed threshold whenever traffic grows, so it notifies you on busy days regardless of whether anything is wrong. Use it only where any occurrence matters and volume is naturally low, such as a payment or signup namespace. Scope it tightly and set a low threshold.Are requests getting slow?
Use: An anomaly detection trigger on performance, measured in milliseconds Averages hide slow requests for part of your traffic. If one request in 20 takes 8 seconds while the rest are quick, the average barely moves, but 5% of users experience a slow request. Percentiles fix this. A p95 of 400 ms means 95 out of every 100 requests finished within 400 ms, and the slowest five took longer. Alert on p90 or p95 rather than the average, so you notice a problem that affects part of your traffic.
AppSignal’s suggested trigger uses a mean above 500 ms, which is a reasonable first alert but will miss partial degradation. Move to p95 once you have a baseline.
To watch one critical path rather than a whole namespace, use an action-scoped performance trigger. Checkout, sign-in, and search are common candidates. Give each a threshold that fits it: a page that calls a third-party API may reasonably take 10 seconds, while a homepage should not.
Did traffic disappear?
Use: An anomaly detection trigger on throughput, measured in requests per minute A sharp drop in throughput usually means a failure happened before requests reached your app: an expired domain, a misconfigured load balancer, or a CDN outage. This failure is invisible to your other alerts, because an app receiving no traffic reports no errors and no slow requests.
Set the threshold against your quietest period, not your average, or the trigger will notify you every night. If your traffic varies too much for a fixed floor to work, alert on traffic reaching exactly zero instead, as described in the following section.
Alerting on traffic that is too high
Traffic far above your normal peak can also need a trigger. It can come from expected growth, such as a successful campaign, or from a problem, such as a bot scraping your catalog or a client retrying in a loop. In both cases, the alert helps you respond before the traffic exhausts your capacity. Set the comparison to More than, with a threshold well over your busiest normal hour, and route it to chat. It is rarely urgent enough for on-call notification, but it explains many other alerts that arrive shortly afterwards.Did activity stop?
Use: An anomaly detection trigger with a threshold of exactly zero Some of the most valuable alerts are about absence rather than excess. A queue consumer that stops consuming, a namespace that stops receiving traffic, or a pipeline stage that stops producing output can show no errors, no slow requests, and no saturation. The missing activity is the problem.
Enabling treat missing datapoints as 0 is what makes this work. Without it, a metric that stops reporting entirely sends no data points, so the trigger has nothing to evaluate and the alert never opens. With it, AppSignal treats missing data as zero and the alert opens as intended.
Good candidates are throughput per namespace, a counter of successfully processed jobs, or a process count that should never drop to zero. This pattern is also the reliable way to notice a worker that has died rather than slowed down.
Use this for continuous work that should always be happening. For work that runs on a schedule, use check-ins instead, which are built for it and do not need a warm-up long enough to span the gap between runs.
Is work backing up?
Use: An anomaly detection trigger on queue time, measured in milliseconds Queue time measures how long a request or job waited before your app started processing it. Rising queue time is an early warning that capacity is short, usually before response times or error rates react. Your app may report no errors and no slow requests while users are still waiting: an order confirmed hours after it was placed, or a report that arrives a day late.
In practice, queue depth is often the easier signal to alert on. If you already track pending job count or unprocessed message count as a custom metric, a depth threshold is concrete, easy to reason about, and easy to set from history. Tag it by queue name so a backlog in one queue does not read as a general outage.
Use both where you can. Depth tells you the backlog is growing; queue time tells you it is already affecting someone.
Are hosts running out of resources?
Use: Host metric triggers Host alerts describe causes rather than user-visible symptoms, so route them to lower-urgency channels than user-facing alerts. A host at 95% CPU with healthy response times is not an incident. Host alerts are useful because they warn you before a resource runs out completely, which is when an app can stop abruptly and other alerts can start opening at once. Every host trigger accepts a hostname, and its default value of* matches every host. Set a specific name or a prefix such as web-* unless you genuinely want one alert per host in the fleet.
Disk usage
This is the clearest host alert to configure, because a full disk reliably causes failures and disk usage often increases predictably.
Set the threshold from how fast the disk fills, not from how full it is. A general-purpose host that gains a percentage point a week is fine at 80%. A database or queue host that can gain 20 points in an hour needs to warn you at 60%, because the remaining time matters more than the remaining space.
That usually means several disk triggers rather than one, each scoped to a group of hosts with a wildcard, such as
db-* at 60% and web-* at 80%. Set one trigger per mountpoint you care about too. A trigger without a mountpoint tag matches every mounted filesystem, including short-lived container mounts.
Memory usage
Percentage is usually easier to reuse across differently sized hosts. Absolute values are better when you know how much free capacity a specific workload needs.
Swap usage
When a server runs low on memory it starts moving data to disk, which is far slower than memory. The application keeps working, so no error may occur, but requests can become slower. This is useful to alert on because the impact can be gradual and easy to miss.
The suggested trigger in AppSignal notifies you when a host uses any swap at all, which is a reasonable way to discover whether your hosts swap. It is usually too sensitive to keep long term: many healthy hosts allocate a little swap and never touch it again. Once you know your baseline, move to a percentage threshold so the alert opens for real memory pressure rather than for a few megabytes allocated at boot.
CPU usage and load average
The agent reports CPU per state rather than as a single total, so pick the state that describes the work you care about, and use
iowait when you suspect the host is waiting on disk rather than computing.
Short CPU increases are normal. Only sustained high CPU usage usually needs a notification, and even then it belongs in chat rather than on-call unless it is already affecting response times.
Load average is often the more useful of the two on database and worker hosts, because it counts processes waiting on disk as well as on CPU. It is not comparable across machines, though: a load average of 60 is saturation on a 16-core host and healthy on a 128-core one. Scope a load average trigger to one class of host with a wildcard and set the threshold from that machine’s core count, rather than running a single trigger across a mixed fleet.
Disk and network throughput
The disk I/O and network traffic triggers cover data read from and written to every disk, and data received and transmitted through every network interface. These make better dashboard graphs than alerts for most teams, because a meaningful threshold depends heavily on the workload. Alert on them when you have a known ceiling, such as a provisioned IOPS limit.Did scheduled work run?
Use: Check-ins Anomaly detection cannot reliably tell you that scheduled work did not happen, because a trigger only evaluates data that arrives. Use check-ins for this.
Both use a Maximum duration in minutes rather than a warm-up. For a cron process monitor, AppSignal reports a failure when no event arrives between the start time set by the schedule and the end of that duration. For a heartbeat, it reports a failure when no event arrives within that duration of the last one. Set it longer than the job’s normal variation in start time and run time, so a job that occasionally runs a few minutes late does not notify anyone.
Good candidates are nightly billing runs, backups, data exports, cache warmers, and any long-running consumer.
Is one dependency failing?
Use: Log triggers Some failures never become an incident or a metric. A payment provider that times out and then succeeds on retry leaves no error and no latency spike large enough to notice, but a sustained pattern is worth knowing about. Start from the query that finds the lines. If you are already looking at them in the terminal, that query is the one you have:Shell
Shell
- First After Close for a problem that recovers on its own, so you get one notification each time the problem returns after closing.
- Nth in an hour for a log pattern that matches intermittently by design, where the number of matching log lines is the important signal.
- Every Occurrence only where a single line genuinely matters.
Getting warm-up and cooldown on log data
When a log pattern is too noisy for any of those thresholds, convert it into a metric instead of alerting on the lines directly. Extract a log-based metric from the matching lines, then point an anomaly detection trigger at that metric. That is two commands. First, count the matching lines into a metric. Acounter needs no field, because it is counting lines rather than reading a value out of them:
Shell
Shell
Is a business metric wrong?
Use: An anomaly detection trigger on a custom metric Custom metrics are the only way to alert on application-specific values AppSignal cannot infer, such as successful payments per minute, signups, or the size of a work queue.
This is the one failure no other alert on this page can detect. If a change at your payment provider starts rejecting every transaction, your app stays up, fast, and error-free while nothing is being sold, so only a metric you send yourself can detect it. Graph the metric first, then set the threshold from what you see.
To verify a custom metric in the alerting UI, open Anomaly detection, go to Triggers, select Add trigger, then choose Custom metrics under Other. Enter the metric name and use the chart preview and tag combinations to confirm AppSignal has received the metric.
Next steps
- Tune what you have set up with tune your alerts.
- Read how anomaly detection evaluates triggers.
- Send custom metrics with custom metrics.
- Review notification settings for error and performance incidents.
- Check for coverage gaps with alerting in production.