What HELIX NMS+ does today.

Multi-tenant device fleet

Every router you look after in one place, grouped by the business it belongs to. If you manage networks for other people, their equipment stays theirs — genuinely separated, not just filtered on screen.

Duplicate router reconciliation

Re-add a router and you still have one entry for it. The platform recognises when two entries are the same router, retires the one that no longer works, tells you it did, and asks you when it cannot tell which to keep.

Router identity reconciliation

Each router's name, model, serial number and software version are read from the router itself as soon as it is added or comes back online, not only in a nightly sweep, so the fleet list describes the hardware you actually have.

Two connection modes

Reach a router whether it has a public address of its own or sits behind somebody else's connection. Equipment in a customer's cupboard is as manageable as equipment in your own rack.

Zero-touch enrolment

Adding a router is one script, run once, on the device. It brings itself online with its own credentials — no tunnel to configure by hand, no addresses to type.

Device analytics pane

What a router has actually been doing — traffic, load, memory — over an hour or over a month. Time it spent offline appears as a gap, not as a flat line pretending everything was fine.

Device tools pane

Ping, trace a route, test throughput and see neighbouring equipment, run from the router itself rather than from your desk. You are testing the path that matters, not the one from your office.

Device maintenance pane

Backups, firmware, configuration history and scheduled work for one router, together on one screen.

Live device dashboard

Everything about a single router in one place — traffic, the people on it, logs, tools and direct access — instead of a different tab for every task.

Management access

Every router shows whether it still allows the address Helix manages it from, read from the last nightly check and dated. Where a router has been locked down and Helix is missing from its list, one control adds Helix's address — and only adds: nothing an operator put on that list is ever removed, and a router that admits everyone is never narrowed. The router is read before the change and read back after it. Off by default until it is switched on. The same view shows whether a router's Winbox console is open to anyone, restricted, or switched off — and lets an operator restrict an open console to their own management networks, which they type themselves and which are never guessed for them. The consequence is stated before the change is made.

WAN failover

One probe per WAN link, tested through that link and no other, and the router itself takes that link's route out when the probe fails and puts it back when the link recovers — on the router, unattended, with nothing steering traffic per flow. Helix reads the router's routing first and refuses, naming the route, if the link already carries a route Helix does not own; it never touches a route it did not create. Every policy shows whether the router holds it and whether the link is failed over right now. Off by default on a deployment until it is switched on.

Interface & system telemetry

Load and per-port traffic over whichever period you choose. A reading that could not be taken is shown as missing. It is never drawn as zero.

Device graphs

Processor, memory and traffic graphs for every router, each shown over the last hour, day, two days and the full period your plan keeps. Traffic in sits above the line and traffic out below it, with the peak and the 95th percentile drawn in and labelled, and any interface can be graphed, including quiet ones.

Live wall

A calm wall for the network operations room. Every router as a tile with its health, the ten busiest interfaces, subscribers and routers updating live, and open incidents beside them. Rows move only when the change is real, so the screen stays still until something actually happens, and a router that stops reporting says so instead of looking quiet.

Port dashboard with optics

Which ports are up, which are fibre, and how much light each one is receiving — so a failing optic is visible while it is still working.

Syslog ingestion & security events

Your routers' own logs, collected centrally, with sign-in attempts picked out and rated. You see how many there were and over what period: a hundred attempts in a minute and a hundred over a week are completely different problems.

SNMP polling

Regular readings from every device for traffic and health. When a value cannot be read it is recorded as unknown rather than as a convincing zero.

Firmware update orchestration

Update one router, a batch, or a small trial group first. Your rules about downgrades, minimum versions and pinned versions are applied however the update was started.

Low-flash pre-flight

Refuses to begin an upgrade a device has no room for, and tells you what to do instead — before you are left with a half-updated router in someone's roof.

Configuration backup & diff

Scheduled and on-demand configuration backups, with a readable comparison between any two, so you can see exactly what changed and when.

Configuration baselines

Declare how your devices ought to be set up — time, naming, logging — and bring the ones that have drifted back into line.

Device removal tells you what it destroyed

Removing a router for good also removes the records of everything set up on it — the customer's service, forwarded ports, routes, remote sessions. You are told exactly what went, at the moment you do it and again in the audit trail, so nothing is left on a device you no longer manage without you knowing.

Platform operations console

Every action taken across every network you manage, filterable, showing who asked for it and what the device said back. Where nobody can be identified it says so rather than inventing a name.

Your activity

Your own record of what you have done, across every business you work in — because a person works across companies, not inside one.

Device operations console

The same record for a single router: what was asked of it, and what happened.

Provisioning queue

Work for a router that is unreachable waits its turn and runs when the router comes back, in order, instead of quietly failing.

Configuration baseline apply

Push your declared settings out to the devices that have drifted, with a preview of what will change before it changes.

Orphaned port-forward teardowns

Port forwards this system created are cleaned up when they are no longer needed — and only the ones it created. Anything you set up by hand is left alone.

Orphaned Helix objects on the router

Each night the router's own rules are checked for anything Helix created that no longer has a record behind it, such as a port forward left over after a device was removed. Helix names them and never removes them itself, so your own neighbouring rules are never touched.

Busiest port per device

Opens on the port actually carrying the traffic, rather than the first one in the list.

Device manageability

Tells you when a router answers a ping but will not accept management. That is the failure that otherwise looks perfectly healthy on every screen.

Configuration change detection

Tells you when a router's management services, address restrictions, admin accounts, scheduled jobs or scripts changed between two nightly readings and the change was not made through Helix. The first reading is a baseline and raises nothing; hardening your own router is recorded, not alarmed. A router that has gone unmanageable is reported together with what its management service looked like the last time it was readable, so the alert says what changed rather than only that something is off.

Abandoned device actions

Work that could never succeed is closed and reported, instead of sitting in a queue forever looking like it is about to happen.

Unprovisioned subscriptions

Tells you when a customer record exists that the router was never actually set up for. The usual reports only cover work that was tried and failed, so work that was never tried at all goes unseen — this names the customer, the router and which of the two it is, because they need different fixes.

Billed but never delivered

When you add a client, their first invoice is raised straight away. That is deliberate: if a router is briefly unreachable, the work still goes into a queue and finishes on its own, and you should not lose a month of billing to a few minutes of network trouble. What this watches is the case where that work never finishes. It tells you when someone has been charged for a service that was never set up on their router, and it separates the situations that look identical from the outside: the ones still being retried, which will almost certainly connect by themselves; the ones that have been given up on, which nothing will fix on its own; and — worst — the ones who have already paid. Paying does not quietly resolve it. When someone settles a bill, the system switches their service back on; if that service was never created in the first place there is nothing to switch on, and it says so instead of pretending. The decision is a different one for each of them — connect the client, or withdraw the bill — so you get the count, the breakdown and how long the oldest has been waiting, and you look the individuals up in your own console. Your subscribers' details are never put on a page that does not ask who is reading. It never withdraws a bill by itself: the client may have been connected by hand, and only you know that. Without this, the bill simply ages, becomes overdue, and the reminder goes out to someone who never received the service — or they pay it, and nothing anywhere notices.

Double-billing exposure

While you are moving customers off another billing system, shows you anyone who could end up being billed by both.

Recovery pin (online drains its own work)

The moment a router comes back, it picks up the work that was waiting for it rather than waiting for the next scheduled sweep.

Bulk & mass operations

Do the same thing to many routers at once, with a preview first and a sensible limit on how many run at the same time.

Winbox tunnelling

Open Winbox on a router that has no public address, over the connection the system already maintains.

Web terminal & WebFig proxy

A terminal and the router's own web interface, in your browser, with nothing to install.

Sites

Group your routers by location. Each site lists the routers on it, and the routers on no site are shown as a group of their own rather than hidden. Grouping changes nothing on any router.

Address inventory and conflict detection

Every address your routers hold, and every PPP client they serve, in one searchable list built from what the routers report. A public address configured on two routers is flagged as a conflict; private ranges reused across separate networks are shown as normal. It reads stored router tables, so opening it never touches a router.

IPAM — disposition worklist

Addresses found on your network that nobody has claimed. Accept them or dismiss them — one list to work through rather than a spreadsheet.

Private address probing

A private client address cannot be pinged from outside your network, so it is checked from the router that serves it. The console shows which addresses would be checked on which router, says plainly which ones it will not check and why, and lets you switch the checking on for a whole organisation in one action — telling you afterwards which routers took it and which did not.

IPAM — ICMP liveness

Which of your assigned addresses actually respond, so you can tell what is in use from what is merely written down.

VLAN map across your network

See every VLAN in your organisation and where it runs: which routers carry it, how it appears on each one (a VLAN interface with its address, or a tagged or untagged bridge port), and which routers it links together, each link with the evidence behind it. Bridges show plainly whether VLAN filtering is on or off. A router Helix has not read yet is named as not read, never shown as having no VLANs, and the assistant can explain the map in plain language.

VPN outbound routes

Send particular traffic out by a particular path, managed here instead of by hand on each router.

Tunnel management

The connections that reach your remote equipment: how they are doing, and the ability to rebuild one that has gone bad.

Alert rules & channels

Decide what is worth telling someone about, and where it should go — email, chat, or the console.

Role-based alert routing

The right people get the right alerts. Whoever handles the money is not paged about a radio on a roof.

Alert digests

A regular summary instead of a constant stream, for the things worth knowing but not worth interrupting anyone for.

Incident console

Open problems in one list, and a way to say "I have this" so it stops climbing.

Escalation ladder

If nobody picks a problem up, it moves to the next person, on a schedule you decide.

Splynx service reconciliation

Before you close a service in the old system, check that both systems still describe it the same way. This compares every service you have already brought across and names the fields that disagree — the address, the plan, the login — for each client, because a count of differences tells you something is wrong and gives you nothing to act on. It runs when you ask rather than every time you open the page, because it reads one record per customer from the old system and that is not free. The cost is stated on the button before you press it. A customer the old system would not hand over is listed by name and is never counted as agreeing, so a connection problem cannot read as a service that has disappeared. Services you have not brought across yet are deliberately left out of the totals, and it says so: this check looks only at customers you have already started migrating, so its view of what is left would be a fraction of the real figure. The migration preview answers that over your whole book. It reads both systems and writes to neither.

Alert coalescing

One upstream failure that takes out fifty sites sends you one message about fifty sites — not fifty messages.

Repeating-condition alerts

A problem that is still going on does not shout every few minutes, and does not go silent either. You get one reminder a day that it is still there.

Offline damping

A router that blinks for a few seconds does not wake anybody. One that is genuinely down does.

Health endpoint

A single thing your own monitoring can watch to know the platform itself is healthy.

Plans and tariffs

Set up what you sell — speeds, prices, billing periods — once, and use them across every customer.

Customers & Customer 360

Everything about one customer on a single page: what they buy, what they owe, what they have paid, and what their connection is doing right now.

Statement of account

A printable statement for any customer: every charge, payment and credit in date order with a running balance, for their whole history or a chosen period. Accounts in more than one currency are listed without inventing a combined balance.

Subscriptions

The link between a customer and the service they pay for. Create it, change the speed, suspend it or restore it — and the network is changed to match, rather than by somebody remembering to go and do it.

Recurring invoicing

Each subscription is invoiced automatically when its period comes round, in the currency of its plan and with your tax settings applied. An invoice is due through the whole of its due day where you operate, never part-way through it. If an invoice cannot be raised, the run names the subscriber instead of skipping them quietly, so nobody drops out of billing unnoticed.

Receivables list (who owes money)

Who owes you money, oldest first, with enough detail to actually chase it.

Finance analytics console

Invoice, payment, wallet and recurring-revenue totals for your organisation. Invoices mean bills you actually raised. Payments recorded with no bill to settle are shown beside them as receipts, not counted as billing.

Payment reminders (manual invoices included)

Overdue invoices are chased on a schedule, including one-off charges such as installations, equipment and arrears — the kind that have no monthly service attached and are easiest to forget about. Reminders ask for payment; they never threaten to disconnect anyone, and they never do. Whether an unpaid bill can affect service is a separate setting that stays entirely yours.

Billing holds (freeze a customer)

Put a customer's billing on pause — during a dispute, a payment plan, or while you look into something. Reminders, automatic suspension and data-cap enforcement all leave them alone until you lift it. You choose whether their service keeps running or stops, every hold carries a reason and a date to review it by, and if the router does not confirm a service change you are told that rather than told it worked.

Suspension reach

When you suspend a client, you are told whether the cut actually reached them. Some routers need a rule in place before a suspension bites; where that rule is missing, the product says so instead of reporting that service stopped. If a router sends suspended clients to a payment page rather than cutting them off, it says that too — they are different outcomes and you are usually chasing a bill. Suspensions that work in their own right, like a dialled-in username being switched off, say nothing at all.

Till payment does not buy a second period

Paying a bill at the counter settles it. It does not quietly add another month on top of the one the bill already covered, so a month of money buys a month of service. A customer paying in advance, with no bill outstanding, still buys the period they are paying for.

Deliverability console

Whether your bills and notices are reaching people at all. A customer with no working contact details cannot be chased, and you should know which ones those are before the month end.

Who you cannot contact

The list above is about messages you tried to send. This one is about the people you never could: it checks every subscriber against the ways you can actually reach anyone, and names the ones nothing would get through to. It splits them by who has to fix it, because that is two different jobs. Some have given you no email and no number, and somebody has to ask them. The rest gave you something you cannot send on — a phone, when text messaging is not set up — and one setting reaches all of them at once. It tells you what it could not check rather than quietly assuming the best, and says when it only looked at part of a large book.

Cash desk

Take a payment at the counter, put it against the right invoice, and get the customer reconnected while they are still standing there.

Bank statement reconciliation

Paste in a bank statement and see which payments match which invoices. Anything it cannot read with confidence is refused and shown to you rather than guessed at — a wrong figure in the ledger costs more than an unmatched row.

Magic-link subscriber access

Customers see their bill and pay it through a link, with no account to create and no password to forget.

Scheduled job health

The routine work that runs on its own — whether it ran, and whether it worked.

Credit notes & outage compensation

Credit a customer for time they lost, one at a time or for everybody affected by the same outage.

Reseller & wholesale settlement

If other businesses sell your capacity, work out what each of them is owed and settle up.

Shaping queues view

The speed each customer is actually getting on the router, next to the speed they are paying for.

Traffic vs subscribed capacity

How much of what you have sold is genuinely being used, so you can see where you are overcommitted before your customers do.

Tickets & CSAT

Support requests in one place, and a simple way to ask the customer whether the fix actually helped.

Splynx connector

Connect an existing Splynx system so your customers and plans can come across.

Dry-run migration

See exactly what a migration would do — every customer, every plan, every problem — before a single record is written.

Plan catalogue import

Bring your existing tariffs across instead of retyping them.

Bring your existing subscribers into billing

Already running subscribers on your own routers? Helix reads them and puts them into billing without changing anything on the router: PPPoE logins, business clients on their own VLAN, and static public-IP clients. Passwords, profiles and cut-off customers stay exactly as they are. Each speed tier becomes a priced plan — Helix fills in the name and speed from the router and you set the price — then you choose the first bill date. Anything that cannot be adopted is listed with the reason.

Tariff catalogue and split picker

Choose which tariffs move now and which wait, so business customers can be migrated separately from residential ones.

Tariff-scoped runs

Run a migration for one group of tariffs at a time, rather than all or nothing.

Remembered router map

Match your old system's routers to your Helix devices once, and every screen that needs the pairing offers it back to you — so you confirm it rather than redraw it. Each run tells you whether it used the pairing you just gave it or the one it remembered.

Observed placement

Works out which router a customer is actually on by looking at the network — and refuses to guess when it cannot tell, instead of quietly putting them somewhere plausible.

Coexistence modes

While both systems are running, decide which one is in charge. Without that, one system cuts a customer off and the other restores them, on their own schedules, forever.

Billing readiness — can this tenant bill a client today?

Before you send anyone an invoice, a short list of the things that have to be in place: a billing configuration, a plan priced in your currency, a router the system can reach, and a way to actually reach the customer. Each one either passes or tells you what is missing and who has to fix it. It appears only when something needs attention, so a quiet screen means a quiet screen rather than a check nobody ran. If the check itself cannot run, it says so instead of implying everything is fine. It reads your own records and touches no equipment, so it confirms the groundwork is done — not that a specific customer has been billed.

Import coverage — what Splynx has that Helix does not

A migration tells you how many services it skipped. That one number hides two unrelated things: services your old system itself lists as disabled, stopped or hidden, which are meant to be left behind, and live services you are still selling that did not make it across. Only the second is a problem, and reported together they read as noise. This separates them and puts the number that matters on its own — the customers you are serving today and cannot yet bill here — with one click through to the list, because the fix is per customer rather than a total you can act on. A skip reason the platform does not recognise is shown as its own figure rather than quietly counted as harmless, so a gap is never hidden by something we have not taught it to read yet.

Double-billing detection

Names anyone who could receive a bill from both systems while the move is in progress.

Splynx overlap in the console

The list of services still billing from your old system, on the screen where you manage the connection to it — not in a report somebody has to generate. Each one is named by its id in the OTHER system, because that is what you have to go and find, and the ones already being billed twice come first. It also tells you the order: close the old services first, hand billing over last. Where a record arrived without an id from the old system, it says so and gives you the login instead, rather than printing something that would find nothing if you searched for it. It reads your own records rather than querying the old system, so it opens immediately and is honest about the difference: rows are shown as unchecked, never as finished. If the list cannot be read at all it says that too, instead of showing you an empty screen that looks like there is nothing left to do.

Cleanup worklist progress

Shows which of those customers you have already dealt with. As each service is closed in the old system it moves to a "done" section instead of sitting on the list, so a long migration shows its own progress rather than looking untouched until the very last step. Anything that could not be checked is counted and said out loud, so an unfinished check never reads as finished work.

Where a customer came from

Open a customer during a migration and you can see that they arrived from your old system, which of their services are linked to it, and the id to search for over there. It stays quiet for the hundreds of customers where that is just background. It speaks up in the one case that costs money: your old system is still billing this connection and you have now billed it here too. Then it says how many times, and what to close first. It reads your own records rather than querying the other system, so it says "probably still billing" rather than pretending to know — you may already have closed that service by hand. And if it cannot check at all it says so, instead of leaving you with a clean-looking page that has checked nothing.

Payment sync

Payments taken in the old system come across, so nobody is chased for a bill they have already settled.

Billed-by-nobody alert

When a customer's billing moves from the old system to Helix, Helix checks every hour that each of their active services is billed by one of the two. A service that neither bills raises an alert naming the customer and the service, once and then daily while it lasts, so nobody quietly gets service for free.

Cohort import

Move a group of customers together — checked row by row first, with every problem listed by line, so you fix a spreadsheet rather than a live network. Customers the old system has already stopped are left out and listed by name, so a migration does not quietly reconnect and bill somebody who left. A large customer book can be read in one go in the background rather than a page at a time.

Organisations & memberships

People, and the businesses they are allowed to work in. Somebody can work across several without seeing everything.

User management

Invite people, decide what they can do, and remove them when they leave.

Organisation settings

Currency, tax, billing behaviour and contact details, set per business.

Organisation suspension

An account can be paused in two steps: monitoring of its routers carries on while everything else stops and staff can only read, or everything stops. Staff are told plainly who to contact. A pause never loses a subscriber's payment and never cuts off a subscriber who has paid, and when it ends, the work that was held back is picked up where it stopped.

Tenant isolation

One business's data cannot be reached from another's. That is enforced on every request, not merely hidden in the interface.

Audit trail

Who did what, and when — including the things that were refused.

Finance scope separation

Access to the money is granted separately from access to the network. Somebody can run the routers without seeing the books.

API keys

Scoped keys that expire, for your own integrations.

Credential encryption

The passwords Helix uses to log in to your routers are encrypted where they are stored. Older tunnel keys are still being moved to encrypted storage, and the SNMP community is stored as it is sent, because SNMP sends it in clear.

Pull-based deployment

Updates are collected by your server rather than pushed into it, so no outside system holds the keys to your platform.

Production log watch

The platform reads its own error logs every half hour and tells the people who run it the first time a new kind of error appears, with personal details taken out of the lines it quotes. An error it already knows about does not alert again, so the alerts that do arrive are worth reading.

Upgrade page during a deploy

While the console is being upgraded, your staff see a page that says so and reloads itself when the console is back, instead of a bare gateway error. An unexpected outage is worded as one, never as an upgrade. Guests on a venue hotspot are unaffected, because their login page is served by the router.

Command palette

Press Ctrl-K anywhere in the console and type. A router, a subscriber login, a customer, a venue or any page is two keystrokes away, and you only ever see what your account is allowed to see.

Scheduled jobs

The recurring work the platform does on your behalf, and a record of every run.

Project tasks tracker

What is being worked on, written down rather than held in somebody's head.

Retention

How long logs and measurements are kept, by plan. Old data is cleared on a schedule instead of growing until something breaks.

Billing and delivery signals

One table that says whether your billing is actually working: customers billed twice during a migration, notices that reach nobody, suspensions that do not cut, and services billed but never switched on. Anything that was not measured says so.

Backup console

Database backups: when they ran, whether they worked, and how to restore one.

Emergency backup

Take a backup right now, before you do something you are not sure about.

Backup event log

The history of every backup and every restore.

MikroTik news & product feed

Vendor announcements and releases relevant to the equipment you actually run.

Fleet service exposure

Which of your routers are offering services to the internet, so you can close what should never have been open.

Public privacy notice & terms

The published privacy notice and terms of service.

Console public overview

A public page explaining what the console does, for people who have not signed up yet.

Sign-in modal

Signing in without losing the page you were on.

Signed-in awareness on the product site

The site recognises that you are already signed in and takes you straight to your console.

Emailed links and the console host

Links in the messages your customers and staff receive always point at the address people actually sign in to, and that address can be changed in one place without touching a single router. Equipment and payment providers keep talking to the address they were set up with, so rebranding the site your customers see never interrupts the network underneath it.

Releases & advisories

What changed in each RouterOS release, and MikroTik's security advisories, in one place in your console.

AI engine and AI section

An AI section in each organisation's console, switched on per organisation by Helix with a monthly cap. Nothing is sent to the AI service until your organisation's owner agrees, and that agreement is recorded. Router and customer names are replaced by stand-ins before anything leaves the platform. Every call is reserved against your organisation's cap before it is made, refused once the cap is spent, and its cost is shown in your usage view.

Org AI assistant

The on-call half of your digital NOC and SOC. Ask a question about your network in plain words and get an answer with the data it read listed underneath. It reads fleet health, one router's detail, firmware, incidents, backups, recent operations, the busiest interfaces, recent alerts, the VLAN map, bridges and spanning tree, security posture, exposed services, configuration changes, billing and receivables, all from what Helix already stores, so asking opens no session on your routers and changes nothing. Tag a question with one router, or ask from a traffic graph or the VLAN map with Explain with AI. Your conversations are private to you, you can delete them, and they are removed after 90 days. It only works once your organisation's owner has agreed.

Telegram assistant

Ask the same assistant from Telegram, and get your organisation's alerts there as they happen. Link your own account once from your profile, choose the organisation, and ask about routers, the busiest ports, incidents or backups from your phone. Owners and admins can have alerts arrive in the chat from the severity they choose. It answers only in a private chat, checks your role on every message, and nothing runs from a chat message: anything it suggests doing waits for a person to approve it in the console.

Daily AI briefing

Every night the AI engine reviews the last 24 hours of your network and its security, for the whole organisation and router by router, and writes a briefing: traffic against the week before, outages, routing and port events, configuration changes, alerts, router logins, your team's console sign-ins, backups and firmware. Every finding carries its severity in words, the evidence, an action, and whether it is new, still open or resolved since yesterday. Rules written in code raise the first findings for every organisation; the AI writes on top of them only where your owner has agreed, and its own findings are marked as not verified by code. During the beta, Helix pays for it.

Admin AI console

Every AI request the platform makes is kept and can be reviewed: what was asked, what was sent to the AI service with subscriber details already hidden, what came back, and what it cost. Nothing the AI suggests becomes part of the platform's knowledge until a person has read it and agreed.