How should an RMM handle load shedding and power outages in South Africa?

A good RMM handles South African power instability by suppressing "device down" alerts during scheduled outages, monitoring UPS and battery state, distinguishing "offline" from "down", and scheduling patching and backups around power windows. Even though Eskom recorded 455 consecutive days without load shedding by mid-August 2026, load reduction and municipal outages still take endpoints offline predictably.

Is load shedding over in South Africa?

National load shedding has been suspended for an extended period, but that is not the same as power instability being solved.

According to Eskom's media statement of 14 August 2026, South Africa had recorded 455 consecutive days without load shedding since 16 May 2025, with a year-to-date Energy Availability Factor of 67.55% — described by Eskom as the strongest performance in six years. The 365-day milestone was passed on 16 May 2026.

Three things still take endpoints offline:

Load reduction. This is a different mechanism from load shedding and it is often confused with it. Load reduction is a localised measure applied where distribution infrastructure — typically transformers — is at risk of overload, and it affects specific areas rather than the national grid. It has shrunk substantially: Eskom reports roughly 1.2 million customers removed from load-reduction schedules, or about 71% of the 1.69 million originally affected, with the Eastern Cape becoming the seventh province declared load-reduction-free. But it has not disappeared.

Municipal and local faults. Cable theft, substation failures, transformer faults and municipal maintenance continue to cause unscheduled outages that have nothing to do with Eskom's generation capacity.

Future supply risk. The National Transmission Company South Africa's Medium-Term System Adequacy Outlook 2025 flags a supply-adequacy risk in the 2029–2030 period as coal stations reach end of life. Eskom also continues to caution about winter risk.

The practical conclusion for anyone specifying an RMM: design for power interruption as a normal operating condition, not an emergency. If load shedding returns, you are ready. If it does not, you still handle load reduction and local faults gracefully.

Why does power instability create false RMM alerts?

An RMM works by expecting a heartbeat from each agent. When the heartbeat stops, the platform raises an alert. That logic is correct in most of the world and badly wrong during a scheduled outage.

Consider a small MSP managing 40 endpoints across a client site that loses power for two hours. Without power awareness, the platform generates:

• 40 "agent offline" alerts as devices lose power
• Alerts for every monitored service on the affected servers
• Network device down alerts for the switch, firewall and access points
• Backup job failure alerts for anything scheduled in the window
• Another 40 "agent back online" notifications when power returns
• Possibly disk or event-log warnings from the ungraceful shutdown That is well over a hundred notifications for an event the technician already knew about. Do that a few times a week and technicians stop reading alerts — which is precisely when a genuine failure slips through. This is the mechanism by which power instability degrades monitoring quality: not by breaking the tool, but by training the humans to ignore it.

What is the difference between "offline" and "down"?

This distinction matters more in South Africa than almost anywhere else, and many platforms handle it poorly.

• Offline means the RMM cannot reach the agent. The cause might be power loss, an internet outage, the device being switched off by a user, or a genuine hardware failure.
• Down means the device is reachable at some level but a monitored service or component has failed. A platform that collapses both into one alert type gives you no way to triage. A platform that distinguishes them — and that can correlate a cluster of simultaneous offline events at a single site with a likely power or connectivity cause — lets you ignore the noise and investigate the outlier. The single endpoint at a site that stays offline after power is restored is the one worth a technician's attention.

How does outage-aware alert suppression work?

There are three approaches, in increasing order of usefulness:

Manual maintenance windows. You mark a site as under maintenance and alerts are suppressed. Workable, but it requires someone to remember, and it does not help with unscheduled events.

Scheduled suppression. You configure recurring windows per site — useful where load reduction follows a published schedule for that area.

API-driven suppression. The platform consumes a live outage schedule and suppresses alerts automatically for affected sites. Services such as EskomSePush expose schedule data via an API, and an RMM that can consume it (or that you can wire up via a webhook or script) gets this right without human intervention. If load shedding returns at scale, this is the difference between a functioning alert stream and a firehose.

Ask any vendor directly: can alerts be suppressed on a per-site schedule, and can that schedule be driven by an external API or webhook rather than manual entry?

What about UPS, inverters and graceful shutdown?

Suppressing alerts is the defensive half. The active half is protecting the hardware.

UPS and battery monitoring. If your RMM can read UPS state — on-battery, runtime remaining, battery health, load — you gain early warning of two things: an outage in progress, and a UPS whose batteries are degrading. UPS batteries in high-cycle environments degrade fast, and a UPS that reports "on battery, 2 minutes remaining" is not protecting anything. Many UPS units expose this via SNMP or a USB/network management card, so ask whether the RMM supports SNMP monitoring of network-attached UPS devices.

Graceful shutdown automation. A script triggered by a UPS on-battery event that shuts down servers cleanly before the batteries expire prevents filesystem corruption and failed database transactions. This is one of the highest-value automations available in a South African environment and is worth setting up on day one.

Boot-loop and post-event detection. Repeated hard power cycles damage hardware. After a power event, useful checks include: which devices did not come back, which are reporting disk errors, which had a dirty shutdown, and which are cycling. An RMM that can run a post-power-event health check across a site saves a lot of manual verification.

Patch and backup windows. Scheduling a 2GB patch deployment or a full backup into a window when the site is likely to lose power wastes bandwidth and produces failure alerts. Where outage schedules are known, patch and backup windows should be set around them, with automatic retry.

What should you ask a vendor?

1. Can alerts be suppressed per site on a recurring schedule?
2. Can suppression be driven by an external API or webhook, not just manual entry?
3. Do you monitor UPS and battery state, including via SNMP?
4. Can I trigger a graceful shutdown script from a UPS on-battery event?
5. Do you distinguish "offline" from "down", and can you correlate simultaneous offline events at one site?
6. Can patch and backup windows be scheduled per site with automatic retry?
7. Can I detect boot loops or dirty shutdowns after a power event? Test these in a trial rather than accepting an answer on a call. Cut power to a test site and watch what the console does.

Allocentra was built with these conditions as a design assumption rather than an afterthought, which is a reasonable thing to expect from any platform sold into this market.

FAQ

Is load shedding coming back in 2026? Eskom has not implemented national load shedding since 16 May 2025 and reported 455 consecutive days without it as of 14 August 2026. However, Eskom continues to warn of winter risk, and the NTCSA's 2025 outlook flags supply-adequacy risk in 2029–2030. Treat power interruption as an ongoing planning assumption.

What is the difference between load shedding and load reduction? Load shedding is national rotational curtailment to protect the grid when generation is insufficient. Load reduction is localised curtailment applied where distribution infrastructure such as a transformer is at risk of overload. Load reduction continues, though Eskom reports about 71% of originally affected customers have been removed from schedules.

Can an RMM read the load-shedding schedule automatically? Some can, either natively or via an integration or webhook using a schedule API such as EskomSePush. Ask specifically — this is not a standard feature in globally built platforms.

Does power instability damage hardware? Yes. Repeated ungraceful shutdowns risk filesystem and database corruption, and frequent hard power cycles shorten the life of drives and power supplies. Graceful shutdown automation and post-event health checks reduce this materially.

Should I still monitor UPS if load shedding is suspended? Yes. Local faults, cable theft and load reduction still cause outages, and UPS battery degradation is invisible until you need the UPS. Monitoring it is how you find out before the outage rather than during it.

Suggested internal links

• How much data does an RMM agent use?
• How do you reduce RMM alert fatigue in a South African environment?
• Existing post: South African RMM buying checklist

Sources to cite in the published version

• Eskom media statement, 14 August 2026: 455 consecutive days without load shedding since 16 May 2025; YTD EAF 67.55%
• Eskom: ~1.2 million customers (71% of 1.69 million) removed from load-reduction schedules; Eastern Cape seventh load-reduction-free province
• NTCSA Medium-Term System Adequacy Outlook 2025: supply-adequacy risk flagged for 2029–2030