Skip to content

troubleshooting.md

Latest commit

 

History

History
162 lines (116 loc) · 3.25 KB

troubleshooting.md

File metadata and controls

162 lines (116 loc) · 3.25 KB
title Voice Provider Troubleshooting
description Common custom voice provider problems

Voice Provider Troubleshooting

Provider not found

Error example:

voice provider not found: mango

Check:

- File exists: /usr/local/lib/incidentrelay/voice_providers/mango.py
- Channel config has: "provider": "mango"
- File name contains only letters, numbers and underscore
- IncidentRelay was restarted after adding the file

Provider class is missing

Error example:

voice provider mango must define Provider(BaseVoiceProvider)

Check that your module contains:

class Provider(BaseVoiceProvider):
    ...

The class name must be exactly:

Provider

Config field is missing

Error example:

mango config requires: api_url, api_token

Check provider_config in channel config.

API token is empty

If you use:

"api_token": "${VOICE_API_TOKEN}"

Check that the environment variable exists for the IncidentRelay process.

For systemd:

sudo systemctl show incidentrelay --property=Environment

Or check your service unit / environment file.

Calls are not sent for real alerts

Check:

- Alert status is firing.
- Alert severity is listed in notify_on_severities.
- Alert has an assignee with phone number.
- Channel is enabled.
- Route points to the voice channel.

Callback is rejected

Check:

- Callback URL contains the correct channel_id.
- Callback URL contains the correct callback secret.
- Channel type is voice_call.
- Channel config has the expected provider.
- Provider sends JSON or form data supported by parse_callback().

DTMF does not acknowledge or resolve the alert

Check:

- Provider sends event_type=dtmf or equivalent data that parse_callback() maps to dtmf.
- Provider sends digit.
- Channel config dtmf_actions contains this digit.
- The digit maps to acknowledge or resolve.
- call_id matches the original VoiceCallResult.call_id.

Notification not found for callback

Check:

- Provider returned call_id from place_call().
- Provider sends the same call_id in callbacks.
- IncidentRelay stored external_message_id for the notification.
- Callback is sent to the same channel_id that created the call.

Provider request hangs

Check:

- All HTTP requests have timeouts.
- Provider API endpoint is reachable from IncidentRelay.
- DNS resolution works.
- Firewall allows outbound provider traffic.

Good:

requests.post(url, json=payload, timeout=10)

Bad:

requests.post(url, json=payload)

Testing checklist

Before enabling a provider in production:

1. Create a test voice channel.
2. Set test_phone.
3. Configure only one test severity, for example critical.
4. Trigger a test notification.
5. Check IncidentRelay logs.
6. Check provider-side logs or dashboard.
7. Confirm that call_id is returned.
8. Confirm that call status callbacks are received.
9. Confirm that DTMF callback with digit 1 acknowledges the alert.
10. Confirm that DTMF callback with digit 2 resolves the alert.
11. Confirm that provider errors are visible in IncidentRelay logs.
12. Confirm that secrets and full phone numbers are not logged.
13. Enable the provider for real alert routes.