Monitor alerts and automatic incidents

The alerting section

Every monitor has an alerting section in its configuration form, under Engage → Status → Monitoring. It decides two separate things: who gets told, and what your public status page says.

Notifications

• Notify on Failure — send an alert when the monitor goes down. On by default.
• Notify on Recovery — send an alert when it comes back up. On by default.

Alerts are delivered as webhook notifications, so they can be routed into whatever your team already watches — a chat channel, an on-call tool, or your own service. Set up the destination in Developer → Webhooks.

Keep recovery notifications on. Knowing something came back is as operationally useful as knowing it went down, and it's what stops people chasing an incident that already resolved itself.

Notifications fire on state changes, not on individual failed checks — the failure and recovery thresholds decide when a state change happens, so a flapping endpoint doesn't produce a flood of alerts.

Auto-created incidents

Auto-create Incident goes a step further: when the monitor goes down, AppGram posts an update to your status page automatically, without anyone on your team having to be awake. It's off by default.

When it's on, you also choose an Incident Severity, which is what your users see on the incident:

• Minor Issue — limited impact, a small subset of users affected.
• Major Outage — significant impact, core functionality impaired.
• Critical Outage — severe impact, most or all users affected.

Because an auto-created incident is public the moment it's posted, be deliberate about which monitors get this. It's a good fit for a monitor that watches something users would definitely notice, and a poor fit for an internal dependency where a two-minute blip means nothing to them.

Choosing a setup

A pattern that works for most teams:

• User-facing endpoints — notify on failure and recovery, and auto-create incidents. Users see the outage on your status page before they email you about it.
• Internal and dependency checks — notify on failure and recovery, but leave auto-create off. Your team hears about it; your users don't need to.
• Noisy or experimental checks — raise the failure threshold before turning any alerting off. A check that alerts constantly gets ignored, which is worse than one that doesn't alert at all.

Planned maintenance

Before taking a service down deliberately, pause its monitor from the monitor menu. That stops both the alerts and any auto-created incident. Post a maintenance update on your status page instead, then resume the monitor when you're done.

After an auto-created incident

An auto-created incident starts the conversation; it doesn't finish it. Once your team is on the case, update the incident with what you've found and move it through Identified and Monitoring as you would any other, then resolve it when service is fully restored. See Creating and Managing Incidents for the full lifecycle.