Skip to content

linuxfabrik.lfops.uptimerobot_alert_contact

Delete an UptimeRobot alert contact

Synopsis

  • Deletes a single alert contact on UptimeRobot. Creation and editing are deliberately not implemented because UptimeRobot's API v2 does not expose them - new contacts have to be added through the web UI (which sends an opt-in mail), and existing ones have to be edited there too. Calling this module with state=present is rejected up front with an explanatory error.
  • Identification is by either friendly_name or id; exactly one must be given. When id is set, the lookup goes straight to the numeric ID. When only friendly_name is given, the module lists all alert contacts and matches the friendly_name exactly.
  • When the contact does not exist (no match by either ID or friendly name, or the listing call failed), the module exits with changed=false instead of failing - so a sweep over a static list of contacts to remove stays idempotent.

Available since LFOps 6.0.2.

Optional Parameters

api_key

  • UptimeRobot API key. See uptimerobot_monitor for the resolution order.
  • Type: String.

api_key_file

  • Path to a file whose first line is the UptimeRobot API key. Tilde-expanded.
  • Type: String.
  • Default: ~/.uptimerobot

friendly_name

  • Friendly name of the alert contact to delete. Exact match. Required if id is not given.
  • Type: String.

id

  • Numeric ID of the alert contact. Required if friendly_name is not given. Takes precedence when both are set.
  • Type: Number.

state

  • Only absent is supported. present is rejected because UptimeRobot's v2 API does not expose contact creation or editing.
  • Type: String. One of absent, present.
  • Default: absent

Examples

# UptimeRobot's v2 API does not allow CREATING or EDITING alert contacts via
# the API — they must be added in the web UI (which sends an opt-in mail).
# This module is therefore delete-only, useful for sweeping contacts that no
# longer correspond to an active recipient.

# 1) Delete by friendly_name (recommended — survives ID re-numbering).
- name: 'Sweep a stale alert contact by friendly_name'
  linuxfabrik.lfops.uptimerobot_alert_contact:
    friendly_name: 'old-pager@example.com'
    state: 'absent'

# 2) Delete by ID (when you already have it from uptimerobot_alert_contact_info).
- linuxfabrik.lfops.uptimerobot_alert_contact:
    id: 7068316
    state: 'absent'

# 3) Drive a sweep from inventory: list everything via the info module, filter
#    for the ones you want gone, then delete them.
- linuxfabrik.lfops.uptimerobot_alert_contact_info:
  register: 'ur_contacts'

- linuxfabrik.lfops.uptimerobot_alert_contact:
    friendly_name: '{{ item.friendly_name }}'
    state: 'absent'
  loop: '{{ ur_contacts.alert_contacts | selectattr("status", "equalto", "not activated") | list }}'
  loop_control:
    label: '{{ item.friendly_name }}'

Return Values

alert_contact

  • The alert contact that was deleted (or that would have been deleted, in check mode), as returned by getAlertContacts. Empty dict when there was nothing to delete.
  • Type: Dictionary.
  • Returned: always.

debug

  • Diagnostic information about the operation (one of delete, delete (check_mode) or noop). Stable enough to assert against, not stable enough to be load-bearing.
  • Type: Dictionary.
  • Returned: always.

  • Sample:

    yaml contact_id: 7068316 friendly_name: monitoring@example.com operation: delete

Authors

  • Linuxfabrik GmbH, Zurich, Switzerland (info (at) linuxfabrik (dot) ch)