Alerting in AppSignal - AppSignal Documentation

Alerts help your team notice behavior that needs attention before customers need to tell you about it. In AppSignal, the most useful alerts are specific, routed to the right people, and urgent only when a human needs to act. AppSignal has five alerting systems:

System	Use it for	Example
Uptime monitoring	An external check that your public endpoints still respond	Alert when a health-check endpoint stops returning a `2xx` from any region
Incident notifications	Errors and performance incidents AppSignal already detects in your app	Notify the team the first time an error appears after a deploy, or when a closed incident starts happening again
Anomaly detection triggers	Threshold alerts on built-in and custom metrics	Alert when error rate stays above `5%`, `p95` response time rises, throughput drops, or disk usage crosses `85%`
Log triggers	Patterns in logs that should alert even when they never become an incident or metric	Alert when one payment provider starts logging repeated timeouts
Check-in triggers	Cron jobs, heartbeats, and other processes that should report on time	Alert when a nightly job does not finish, or a worker stops sending heartbeats

Uptime monitoring checks your endpoints from AppSignal’s servers in multiple regions over the public internet; the other four alert on data your app already sends to AppSignal. Many teams set it up first, because it catches an outage even when the app can send nothing at all.

What alerts are

Alerts turn telemetry into action. They help you answer questions such as:

Is the app down?
Are users seeing more errors than usual?
Did traffic drop because something upstream failed before requests reached the app?
Is a background queue backing up?
Did a scheduled job stop running?

A good rule of thumb is to alert on the symptoms users feel, not every internal cause. That is the idea behind the SRE “four golden signals”: latency, traffic, errors, and saturation. In AppSignal, those map to response time, throughput, error rate, and host metrics and queue growth.

Choose the right alerting system

Use incident notifications when AppSignal already has an incident and you want to control who gets notified and how often. This is a strong default for exceptions and slow actions you already know you care about. Use anomaly detection triggers when you want threshold-based alerting on metrics. This is the most flexible option for SRE-style coverage, including error rate, response time percentiles, throughput, queue time, host metrics, and custom metrics. Use log triggers when the signal exists in logs but not yet as a dedicated incident or metric. They work well for integration-specific failures, such as one bank or provider timing out while the rest of the system looks healthy. Use check-in triggers when success means “this process reported on time.” They are the right tool for cron jobs, heartbeats, workers, and scheduled tasks.

A practical starter set

For most production apps, a useful starter set looks like this:

An uptime check for your public health-check endpoint.
An anomaly trigger for web error rate.
An anomaly trigger for p90 or p95 response time on critical user-facing traffic.
An anomaly trigger for throughput drops.
An anomaly trigger for queue time, queue depth, or background job backlog.
Host metric triggers for CPU, memory, and disk.
Check-ins for cron jobs, scheduled tasks, and long-running workers.

Popular alerts to start with

These are common first alerts for teams that want broad coverage without too much noise:

Alert	Why it helps	AppSignal feature
Error rate in the `web` namespace	The fastest signal that users are hitting breakage	Anomaly detection trigger
`p90` or `p95` response time for critical actions	Averages hide a slow experience for part of your traffic	Anomaly detection trigger
Throughput drop	A sharp drop often means something upstream failed before requests reached your app	Anomaly detection trigger
Queue time or backlog growth	Early warning before users notice delays	Anomaly detection trigger
CPU, memory, and disk usage	Infrastructure heads-up for saturation and capacity problems	Anomaly detection trigger
Health-check endpoint failing	Confirms the app is unreachable from outside your infrastructure	Uptime monitoring
Cron job or worker heartbeat missing	Confirms expected background work still runs	Check-in trigger

What SREs commonly want coverage for

If you are building out alert coverage from scratch, these are common priorities:

User-visible errors
Slow user requests, especially at p90 or p95
Traffic drops and unusual throughput changes
Background queue growth and delayed jobs
Host saturation such as CPU, memory, and disk
Scheduled jobs that fail to start, finish, or report
External dependency problems such as slow bank APIs, timeouts, or retry storms

This is also why deploy markers matter even though they are not an alert type on their own. They help you answer whether the alert started right after a release.

Configure alerts successfully

Good alerting is mostly about scope and routing:

Add notifiers first on the Integrations and Notifications pages. Each trigger can use a different notifier, so you can route by severity.
Send urgent production alerts to an on-call tool such as PagerDuty, Opsgenie, or another webhook notifier.
Send warnings and degradations to chat or email, such as Slack. Give staging its own channel or mute it.
Set notification defaults per namespace so web, background, and admin can notify different teams by default.
Start with alerts tied to user impact, then add narrower operational checks once you see what is useful.

Avoid noisy alerts

This is the part that separates a useful alert from one the team learns to ignore:

Set thresholds from real history, not guesswork. Review a few weeks of the metric’s trend before choosing a threshold.
Use warm-up windows so a condition must hold for several minutes before the alert opens. Three to five minutes is a common starting point, and most false alarms are single-minute blips.
Use at least a one-minute warm-up on uptime monitors to ride out brief network hiccups.
Add a cooldown so a flapping signal becomes one longer alert instead of opening and closing repeatedly.
Prefer rates over absolute counts when traffic changes through the day. Error rate is usually more useful than raw error count.
Prefer p90 or p95 for latency-sensitive alerts instead of relying on averages.
Scope alerts by namespace, action, or tags so the notification says exactly what is affected.
One good sustained alert beats five twitchy ones. Send only urgent, customer-facing alerts to on-call, and everything else to chat.

Set up uptime monitoring

Create a dedicated health-check endpoint if you do not already have one.
Add an uptime monitor for that endpoint.
Choose a notifier for downtime notifications.
Set at least a one-minute warm-up so brief network hiccups do not open alerts.
Ignore the health-check endpoint in your AppSignal app if you do not want those requests counted toward your monthly request volume.

Use uptime monitoring for “is the app reachable from outside?” Use check-ins for “did this scheduled or background process report on time?”

Examples

Incident notification example

Use incident notifications when AppSignal already created an error or performance incident and you mainly need the right notification behavior. For example:

Use First in Deploy for production errors that should only alert once per release.
Use First After Close for incidents caused by external systems that may recover without a deploy.
Use Every Nth per Hour or Every Nth per Day for noisy known errors where volume matters more than each individual occurrence.

Pairing incident notifications with deploy markers makes it much easier to answer, “Did this start after our last deploy?”

Log trigger example

Use log triggers when logs contain the signal you need. For example, a payment or signup flow may retry when a bank API is slow, so one failure may not deserve an urgent page, but a sustained pattern does.

SQL

severity=error provider=bank-a message:timeout

A trigger like this can notify the team when one provider starts timing out. If retries are common, use First After Close or Nth in an hour instead of alerting on every matching log line.

Custom metric alert example

If you send custom metrics, you can alert on them with anomaly detection. For example, you might send:

A counter for successful payments or signups
A gauge for queue depth or active worker count
A measurement for provider response time

After the metric appears in AppSignal:

Graph it first and review its recent history.
Choose the field that matches the question you are asking: gauge, counter, count, mean, p90, or p95.
Filter by tags such as provider=bank-a or region=eu when you need a narrower alert.
Add the right notifier for the severity of the problem.
Add warm-up and cooldown before you rely on the alert in production.

Next steps

Review notification settings for incident-based alerting.
Create anomaly detection triggers for metrics and thresholds.
Set up uptime monitoring for an external health check.
Create process monitors and check-ins for cron jobs and heartbeats.
Use log triggers for log-based alerting.

​What alerts are

​Choose the right alerting system

​A practical starter set

​Popular alerts to start with

​What SREs commonly want coverage for

​Configure alerts successfully

​Avoid noisy alerts

​Set up uptime monitoring

​Examples

​Incident notification example

​Log trigger example

​Custom metric alert example

​Next steps