Monitoring & alerting.
An alert is only as good as the person who receives it and the instruction that comes with it. That is why every threshold has a recipient and every alert becomes a ticket.
- Agent on every device, network via SNMP/API, Microsoft 365 via service health and identity
- Thresholds per device type, tuned against alert floods
- Every alert automatically becomes a ticket in the service portal
- Service hours Mon–Fri 08:00–18:00; on-call outside agreed per client
- Digital employee experience: sign-in times, crashes, device health — analysed, not just collected
Monitoring & alerting
Servers: CPU, RAM, storage, services, event logs, backup jobs, certificates. Workplaces: health, disk, EDR and patch status, pending reboots. Network: firewall, switches, Wi-Fi controllers, internet connection — reachability and utilisation. Microsoft 365: service health, sign-in anomalies via the identity platform. Plus the user experience: how long sign-in takes, which application crashes, which device is getting slow — before someone calls.
Availability and alerts in the monthly report
Outages with duration and cause, alert counts by category, devices with conspicuous user experience — and what we did about it.
- Outages: system, start, duration, cause, action
- Alerts by category and criticality
- Response time on critical alerts
- Devices with DEX findings and status
- Thresholds adjusted this month
Monitoring & alerting — the parameters.
Values set per client are marked "agreed per client".
Agent values every minute; network devices via SNMP/ping at short intervals; M365 service health continuously. Exact intervals set per client and device type.
Per device type: warning and critical separated (e.g. disk space, service stopped, backup job failed, certificate expiring). Starting values from our standard, fine-tuned in the first weeks.
Alert → ticket in the service portal with device, value, time. Critical alerts additionally push/call to the responsible person. Recipients and order are in the escalation matrix.
Mon–Fri 08:00–18:00 response by us. Outside: on-call agreed per client — otherwise handled at the next service start, critical alerts first.
Maintenance windows muted, flapping protection (no alert on brief fluctuations), recurring false alerts are analysed and the threshold adjusted — not the alert ignored.
Sign-in duration, application crashes, blue screens, battery and disk health per device in our OpenSearch analytics. Trend over weeks; conspicuous devices are addressed proactively.
With what — and what is replaceable.
| Tool | Role | Data location | Replaceable by |
|---|---|---|---|
| RMM-Plattform | Agent monitoring, thresholds, automations, remote access | EU instance | any RMM with monitoring |
| Serviceportal | Alert becomes ticket; escalation, history per device | operated by us, Germany | data portable via export/API |
| OpenSearch (eigene DEX-Auswertung) | User experience per device: sign-in, crashes, health, trends | operated by us, EU | open format, exportable |
| Wazuh | Log collection and detection (see Managed SIEM) | operated by us, EU | open source — rules and data are yours |
What we deliberately do not do
- No "24/7 monitoring" as a promise without agreed on-call — watching is around the clock, responding is at the agreed times
- No alert without a recipient and an instruction
- No collection of user data beyond what operations need — DEX measures devices, not people
Prerequisites on your side
- RMM agent on all devices
- SNMP or API access to firewall, switches, Wi-Fi
- Escalation matrix: who at the client is reachable when
- Agreement on on-call outside service hours — or deliberately none
Questions from IT
Who gets woken up at night when the server is down?
That depends on the agreed on-call. Without on-call: nobody — the alert sits at the top as a critical ticket at service start. With on-call: the person on duty at our end, and per escalation matrix your contact too. We state this clearly in the quote instead of writing "24/7" on the website.
How do you prevent alerts from becoming wallpaper?
By follow-up: every false alert is reviewed and the threshold or condition adjusted. Maintenance windows are muted, brief fluctuations filtered. The goal is that every alert that arrives triggers an action.
Can we see the monitoring ourselves?
Yes — in the service portal: device status, open alerts, ticket history per device. Your IT staff get their own access, on request via SSO with your Entra ID.
What is digital employee experience in concrete terms?
Measurements that describe how a device feels to the person in front of it: sign-in duration, application start, crashes, blue screens, battery, disk. We analyse them over weeks and address conspicuous devices before someone complains — or suffers quietly.
Let's talk about your IT.
An intro call is free and non-binding. We listen, we ask — and we'll say openly whether we're the right people for you.