Get phone and SMS alerts fromeG Enterprise
eG Enterprise watches the whole stack — Citrix and VDI sessions, Java and .NET applications, databases, servers, storage and the cloud underneath them — and raises an alarm the moment a test crosses its threshold. Spike pages a human for it: a phone call, SMS, Slack message or email to whoever is on call, escalating until someone picks it up.
Set up with AI
I use eG Enterprise for monitoring and Spike for on-call and incident management. Walk me through connecting them: create a eG Enterprise integration in Spike, copy its webhook URL, and add that webhook to eG Enterprise alert settings. Then help me send a test alert to confirm incidents show up in Spike.
What is eG Enterprise by eG Innovations?
eG Enterprise is eG Innovations’ full-stack monitoring and observability platform. It instruments the layers a business application actually runs on — the Citrix or VMware virtual desktop, the Java or .NET application server, the database, the operating system, the hypervisor, the storage and the cloud service underneath — and correlates them, so a slow Citrix logon is traced to the layer causing it rather than reported five times over by five different monitors. When a test crosses its threshold, eG raises an alarm with a priority, the component it fired on, and a plain-language description of the problem.
Inside eG, an alarm is a row on a console and, at best, an email into a mailbox nobody is watching overnight. Pointed at Spike through eG’s webhook integration, that same alarm becomes a page: the on-call engineer is called and texted within seconds, and an alarm nobody acknowledges climbs the escalation policy until someone answers. The incident’s title is eG’s own problem description plus the component it fired on — “CPU utilization on citrix-vda-04 has exceeded the critical threshold”, say — so whoever wakes up knows what broke and where before opening anything. The layer, test, measure, zone and service ride along on the incident for the diagnosis that follows.
Because every alarm carries the unique ID eG’s manager assigns it, repeats stay together. An update to an alarm that is already open — a severity escalation, a changed detail — is appended to the same incident as an event rather than paging the team a second time, and two separate alarms on the same component stay two separate incidents. Who gets paged, and how hard, is decided in Spike: alert routing rules read the component, layer, priority and the rest of the payload each alarm arrives with, so a lab server doesn’t wake the same people a production VDI farm does.
And when the problem clears, the sweeping-up is done for you. eG closes the alarm, Spike matches it back to the open incident by alarm ID, and the incident resolves itself — no stale pages left behind for someone to close by hand the next morning.
How to set up eG Enterprise alerts
Every Spike integration is a unique webhook URL. Paste it into eG Enterprise and alerts start flowing — no agents, no code.
Step 1: Create an eG Enterprise integration in Spike
In your Spike dashboard, open Integrations and choose eG Enterprise. Spike generates a unique webhook URL for this integration — copy it, and attach the integration to the service and escalation policy that should answer these alarms.
Step 2: Open the webhook integration in eG
In the eG admin console, go to Settings → Manager → ITSM/Collaboration Integration → Webhook Integration and add a webhook. Paste the Spike URL as the endpoint and leave the authorization type set to none — the token in the URL is the credential, the same as every other Spike integration.
Step 3: Paste the payload template
eG lets you define the JSON it posts. Paste Spike's template, which maps eG's own alarm variables — the alarm ID, component, layer, test, measure, problem description, priority and the alarm's state — onto the fields Spike reads. One URL and one template cover every alarm state, so there is nothing to configure per alarm type.
Step 4: Watch an alarm become an incident
When eG raises an alarm, Spike opens an incident titled with the problem description and the component it fired on, so the alert reads on a phone lock screen without opening eG. Later updates to the same alarm join that incident instead of paging again, and when eG closes the alarm the incident resolves itself.
That's it — eG Enterprise alerts now page whoever is on call.
