Problem Statement
A Minor alarm is raised on Avaya Application Enablement Services (AES) with maintenance object avAesServiceDown and description "AES Service died unexpectedly." The alarm may appear as an active/open alarm in the monitoring dashboard.
Impact
One or more AES services may have stopped unexpectedly. Applications that depend on AES integrations may experience degraded or unavailable CTI/API functionality until the affected AES service is restored.
Alarm
avAesServiceDown - AES Service died unexpectedly
Troubleshooting Steps
- Confirm the alarm details in the monitoring dashboard: device type Avaya Application Enablement Services (AES), alarm severity, maintenance object avAesServiceDown, alarm code ACT, and current alarm state.
- Check whether duplicate alarms or tickets already exist for the same AES host and alarm. If a parent incident exists, merge or link the duplicate and continue work in the active parent record.
- Verify management connectivity to the AES system using approved access methods for the environment.
- Log in to the AES management interface or system console using authorized credentials.
- Review AES service status and identify which AES service stopped unexpectedly.
- Check recent AES/system logs around the alarm timestamp for service crash, restart, dependency, resource, licensing, or connectivity errors.
- If operationally approved, attempt to restart the affected AES service using the standard Avaya AES administration procedure for the installed version.
- After restart, confirm the service remains running and verify that dependent applications or integrations have recovered.
- Monitor the dashboard to confirm the avAesServiceDown alarm clears. If the alarm remains active or returns, collect logs and escalate to the Avaya/AES support team or the responsible voice applications team.
- Document the affected service, timestamps, observed errors, actions taken, and final alarm state in the incident record.
Resolution
In the referenced case, the duplicate request was closed and merged into an existing request for continued handling. For active occurrences, resolve the incident only after the affected AES service is restored and the avAesServiceDown alarm clears or is otherwise validated as handled in the parent incident.