In development since April 2026, inside a working ISP

Find the fiber break and every customer it took offline

Eldaven is outage operations software for local ISPs in Indonesia. Machine learning reads every alarm from your MikroTik and fiber network, groups them into incidents and writes the first report. A language model is called in only when an incident needs real reasoning.

Blok C service area. Click any cable to cut it.

Simulated network. In a real deployment, Eldaven builds this map from your routers, OLT and customer records.

We built it for our own ISP first

I run a small internet provider in Indonesia. For years, every outage started the same way: customers messaging us on WhatsApp before our team knew anything was wrong.

In April 2026 I started building tools to fix that on our own network. Most local ISPs run exactly like we do, so we're turning those tools into a product.

Hezron SitanggangFounder
Bu SriInternetnya kenapa ya?
YusufLampu LOS di modem merah
Andi, WarkopBang, ada gangguan di daerah sini?
Kost MelatiSemua kamar wifinya mati kak
Bu Rina, Blok CMin, internet mati lagi ya? Anak saya lagi ujian online
EldavenThese 5 chats are one fault: fiber cut between ODC 3 and ODP 3C, 8 customers affected. Technician notified.

Machine learning reads every alarm. A language model sees only the hard cases.

Small, fast models do the volume work on your own server. When an incident doesn't fit a known pattern, Eldaven can hand it to the LLM of your choice for a deeper look.

Of 0 alarms, 0 became incidents and 0 needed a language model. That's 0% of alarms. Simulated; real ratios depend on your network.

Why not send everything to an LLM?

Cost and speed. A small ISP sees thousands of alarms a day. Sending each one to a language model would cost more per month than many customers pay, and every answer takes seconds. ML models run locally in milliseconds with no usage fee, so they carry the load.

Then why use an LLM at all?

Some incidents don't match any pattern: a fault after a config change, or symptoms spread across sites. There, a language model can read logs and history, compare explanations, and write them up in plain Bahasa Indonesia. It's a tool for the hard 1%, not the routine 99%.

ML engineAlways onLanguage modelOptional, on demand
DoesDetects unusual traffic, signal and session patterns. Groups alarms by cable. Runs standard read-only checks. Writes the incident note.Investigates unusual faults across logs and config history. Explains its reasoning. Drafts updates for customers.
RunsOn every alarm, around the clock.When ML marks an incident as unclear, or a technician asks.
LivesOn your server, next to your network.Your provider and your API key: Claude, Gemini, GPT, or an open model on your own hardware.
CostsNo usage fee.Billed by your provider, capped by a monthly limit you set.

Outage tracing is the core. The same map serves the whole team.

Once Eldaven knows which customer sits behind which cable, that knowledge is useful far beyond the NOC: to CS, to field technicians, and to whoever plans the next upgrade.

Core

Outage tracing

Alarms and complaints become one incident, with the exact list of affected customers and the most likely location of the fault. After the repair, Eldaven re-runs the checks and closes the incident only when every customer is back.

CapabilityWhat it doesStatus

Network and customer map

Every customer's path from POP to ODC, ODP and port. Click any device to see whose service depends on it.

First version

Repeatable checks

Your best technician's know-how as checks anyone can run: customer offline, PPPoE drops, slow at peak hours, DNS trouble, problems after a config change.

First version

Answers for customer service

Look up a customer and see at once whether they're part of an outage, with a reply that doesn't promise a repair time nobody knows yet.

Next

Field technician tasks

The location, the likely ODP, the readings to take and the customers to compare against. Results are logged from the technician's phone.

Next

Configuration history

Router configuration snapshots compared over time, so you can see what changed right before something broke.

Next

Shift handover and memory

The next shift sees what was checked and what's left. Confirmed causes are saved, so the same fault is solved faster the second time.

Next

Capacity planning

Forecasts when peak-hour traffic will reach your uplink limit, so you can upgrade before customers feel it.

Later

Maintenance planning

Before scheduled work, see which customers will be affected and which checks to run afterwards.

Later

Works with the equipment local ISPs already run

No new hardware and no change to how your network is configured. Eldaven connects with read-only access to what you have.

AreaIntegrationHow it connectsStatus
RoutersMikroTik RouterOS 6 and 7API, REST and SNMP, through a read-only userFirst version
Other SNMP devicesSNMP v2c and v3Later
FiberSFP optical readingsRx and Tx power from MikroTik SFP portsFirst version
OLT and ONT signalOne OLT vendor first, chosen with pilot ISPsNext
CustomersPPPoE sessions and DHCP leasesRead from your MikroTik routersFirst version
Customer listCSV import from your billing systemFirst version
RADIUS and billing systemsDirect integrationLater
AlertsEmail and TelegramIncident notifications to your teamFirst version
WhatsAppUpdates for your CS teamNext
Language modelsNone, ML onlyEverything stays on your serverFirst version
Claude, Gemini, GPTYour own API key, with a monthly spending limitFirst version
Open modelsRunning on your own hardwareLater

How your network data is handled

Customer data and router access are the most sensitive things an ISP has. These are the rules Eldaven is being built around.

Where it runs
On a small Linux server or VM inside your network. The ML engine runs there too.
Router access
A read-only user on each router. Eldaven never pushes configuration changes.
Credentials
Router passwords stay on your server and are never sent to any model.
What leaves your network
In ML-only mode, nothing. With an LLM switched on, only the fields you allow, with customer names replaced by IDs.
Unknown data
A device that stops reporting is marked unknown, never healthy. Every finding links to the reading behind it.

Roadmap

We move to the next stage only when the current one works on a real network.

  1. April 2026

    Started

    First tools built for our own ISP.

  2. Now

    Building the core

    Collector, alarm grouping and the first ML models, built on our own network.

  3. Next

    First pilot ISPs

    Two or three outside ISPs, five checks for common faults, optional LLM investigations.

  4. Later

    Deeper diagnosis

    Billing and RADIUS links, OLT signal data, capacity forecasts, multi-site.

Run the pilot on your network

We're looking for two or three local ISPs to shape the first version with us. Tell us which outages cost your team the most time.

hezron@eldaven.online