# Event Notifications

Each time &repmgr; or &repmgrd; perform a significant event, a record of that event is written into the `repmgr.events` table together with a timestamp, an indication of failure or success, and further details if appropriate. This is useful for gaining an overview of events affecting the replication cluster. However note that this table has advisory character and should be used in combination with the &repmgr; and PostgreSQL logs to obtain details of any events.

Example output after a primary was registered and a standby cloned and registered:

        repmgr=# SELECT * from repmgr.events ;
         node_id |      event       | successful |        event_timestamp        |                                       details
        ---------+------------------+------------+-------------------------------+-------------------------------------------------------------------------------------
               1 | primary_register | t          | 2016-01-08 15:04:39.781733+09 |
               2 | standby_clone    | t          | 2016-01-08 15:04:49.530001+09 | Cloned from host 'repmgr_node1', port 5432; backup method: pg_basebackup; --force: N
               2 | standby_register | t          | 2016-01-08 15:04:50.621292+09 |
        (3 rows)

Alternatively, use to output a formatted list of events.

Additionally, event notifications can be passed to a user-defined program or script which can take further action, e.g. send email notifications. This is done by setting the `event_notification_command` parameter in `repmgr.conf`.

The following format placeholders are provided for all event notifications:

`%n`

  node ID

`%e`

  event type

`%s`

  success (1) or failure (0)

`%t`

  timestamp

`%d`

  details

The values provided for `%t` and `%d` may contain spaces, so should be quoted in the provided command configuration, e.g.:

        event_notification_command='/path/to/some/script %n %e %s "%t" "%d"'

The following parameters are provided for a subset of event notifications; their meaning may change according to context:

`%p`

  node ID of the current primary ( and )

  node ID of the demoted primary ( only)

  node ID of the former primary (`repmgrd_failover_promote` only)

`%c`

  `conninfo` string of the primary node ( and )

`%a`

  name of the current primary node ( and )

The values provided for `%c` and `%a` may contain spaces, so should always be quoted.

By default, all notification types will be passed to the designated script; the notification types can be filtered to explicitly named ones using the `event_notifications` parameter, e.g.:

        event_notifications='primary_register,standby_register,witness_register'

Events generated by the &repmgr; command:

- `cluster_created`

- `primary_register`

- `primary_unregister`

- `standby_clone`

- `standby_register`

- `standby_register_sync`

- `standby_unregister`

- `standby_promote`

- `standby_follow`

- `standby_switchover`

- `witness_register`

- `witness_unregister`

- `node_rejoin`

- `cluster_cleanup`

Events generated by &repmgrd; (streaming replication mode):

- `repmgrd_start`

- `repmgrd_shutdown`

- `repmgrd_reload`

- `repmgrd_failover_promote`

- `repmgrd_failover_follow`

- `repmgrd_failover_aborted`

- `repmgrd_standby_reconnect`

- `repmgrd_promote_error`

- `repmgrd_local_disconnect`

- `repmgrd_local_reconnect`

- `repmgrd_upstream_disconnect`

- `repmgrd_upstream_reconnect`

- `standby_disconnect_manual`

- `standby_failure`

- `standby_recovery`

- `child_node_disconnect`

- `child_node_reconnect`

- `child_node_new_connect`

- `child_nodes_disconnect_command`

Note that under some circumstances (e.g. when no replication cluster primary could be located), it will not be possible to write an entry into the `repmgr.events` table, in which case executing a script via `event_notification_command` can serve as a fallback by generating some form of notification.