The account_alerts webhook

What arrives on this channel?

Whatever Meta considers worth flagging about the account, which is deliberately open ended and has expanded over time.

Because the contents are not a fixed set, a handler written to switch on specific alert types will miss new ones. The durable approach is to record the alert, attach it to the account, and surface it to a human, rather than to map each variety to an automatic response.

This is the one operational event where the honest handling is to notice rather than to decide. Our own handler records that an alert arrived and does not attempt to infer a status from it.

How should it fit into monitoring?

As a flag on a timeline, next to the events that do carry state.

The value is in the sequence. An alert that arrives shortly before a rejected review and then a restriction tells a story that none of the three tells alone. Recording them on one timeline is what makes that visible, and it is what turns a conversation with a client from guesswork into a date and an event.

What it should not do is trigger anything. An alert is not a disconnection, not a quality drop and not a restriction, and treating it as any of those produces false alarms that teach people to ignore the real ones.

Common mistakes

• Switching on specific alert types. The set expands and a handler built around today's list goes stale.
• Triggering automation from an alert. It carries no state, so anything inferred is a guess.
• Dropping it because it is not actionable. Its value is in the sequence it forms with other events.

Frequently asked questions

Keep reading