Skip to main content
These answers cover common support questions about AppSignal alerts. For setup guidance, start with Alerting in AppSignal. For tuning noisy alerts, see Tune your alerts and Reduce alerting noise.

​
Why am I still receiving alert emails after canceling my plan?

Those emails are operational alert notifications, not marketing emails. They usually come from a monitor or trigger that is still configured for the app. For example, an uptime monitor can keep checking a URL and send an alert each time the URL cannot be reached. If your account is locked or canceled, the email may say that AppSignal is still monitoring the app but that you no longer have access to the data details. To stop the notifications:
  1. If you can still access the app, remove the notifier from the trigger on the triggers page, or from the monitor on the uptime monitoring page.
  2. Archive the trigger or delete the uptime monitor if you no longer need it.
  3. If you cannot access the app because the account is locked or canceled, contact support. We can help identify and remove the monitor or trigger that is still sending alerts.

​
How do I stop a trigger from sending notifications without deleting it?

Remove the notifiers from the trigger on the triggers page. The trigger stays active and still records alerts, but it stops sending notifications. Archive the trigger only when you no longer want AppSignal to evaluate that condition. Archiving a trigger also closes its open alerts. For anomaly detection triggers, notification routing is controlled on the trigger itself. Incident notification frequency settings, such as Never Notify or Every Nth per Hour, do not apply to anomaly detection trigger alerts.

​
Can I alert when Kubernetes containers are pending or stopped?

AppSignal for Kubernetes reports node and pod metrics, and shows them on the Cluster Metrics pages. It does not provide a Kubernetes trigger for container states such as pending or stopped. Kubernetes metrics are not currently available for anomaly detection triggers, and the Kubernetes overview does not create alert rules. If you need alerts for Kubernetes container or pod states, contact support. We can help confirm what is possible for your setup and collect the use case if it needs product work.

​
What metric powers the Process memory usage dashboard?

The Process memory usage dashboard, one of your app’s dashboards, uses the process_rss metric. This metric is tagged with:
  • hostname, the host that emitted the metric.
  • process_name, the process name reported by the app process.
To create an alert for a specific process, create an anomaly detection trigger for process_rss and scope it with tags. For example, use process_name=sidekiq* or a specific process name if your app reports one, and use the relevant hostname when you want to alert on one host or dyno. To confirm the exact metric and tags behind a dashboard chart, open the chart menu and select Edit chart. Use the metric name, field, and tags from that chart as the starting point for the trigger.

​
We receive alerts but rarely open AppSignal. Is that a problem?

Not necessarily. Some teams use AppSignal mostly as an alerting system. That can work if the alerts are specific, routed to the right place, and acted on. It becomes a problem when notifications arrive but nobody investigates them. That usually means the alerts are too noisy, not clear enough, or routed to the wrong channel. Review the alert setup:
  1. List the triggers that opened alerts in the last 90 days on the triggers page.
  2. Check whether anyone acted on each alert in the anomaly detection overview.
  3. Remove notifiers from alerts that should not notify anyone.
  4. Archive alerts for conditions nobody needs anymore.
  5. Route urgent alerts to an on-call tool, and route lower-priority alerts to chat or email.
  6. Add a clear trigger name, description, and dashboard link so the notification explains what to do next.
If your team does not want to use the AppSignal UI often, use the AppSignal CLI or AppSignal MCP server to review triggers and investigate alerts from your normal workflow.z

​
Which alerts should send email?

Use email for alerts that should keep reminding someone while they stay open, or for lower-urgency alerts that do not need an immediate on-call response. For urgent production issues, use an on-call notifier such as PagerDuty, Opsgenie, or another webhook-based notifier. Email is easy to miss when a team receives many alerts. Connect notifiers on the Notifications page, then select them on each trigger. Email can send reminders while an anomaly alert stays open. Other notifier types, including Slack, PagerDuty, Opsgenie, and webhooks, receive notifications when the alert opens and when it is resolved.

​
How often should we review alert settings?

Review triggers roughly every quarter, and any time a notification channel starts to feel noisy. Ask these questions for each trigger:
  • Did this trigger open an alert in the last 90 days?
  • Did someone act on it?
  • Did one incident create many alerts?
  • Is the notifier still right?
  • Does the trigger name and description explain the action to take?
  • Does the trigger still match current hosts, tags, queues, or process names?
An alert nobody acts on should be retuned, rerouted, or archived.