The Runtime Core
Three platform areas carry most SDX operations:MikroTik Runtime
Owns site adoption, heartbeats, pending router jobs, callbacks from devices, live state, and site lifecycle events.
Control Plane
Owns management-side orchestration, control plane policies, credentials, transient access, management server routing, and synchronous operations.
Metadata
Stores shared context such as tags, notes, files, site imagery, and resource metadata used across the portal.
Heartbeats and Online Status
Managed routers send regular heartbeats to SDX. Heartbeats update last-seen information, device details, availability state, and metrics inputs. In reporting views, SDX treats a site outage as a missed-heartbeat window: routers report roughly every 30 seconds, and an outage fault is created after 10 consecutive missed heartbeats. That gives the platform a 5-minute sensitivity window before it records downtime. Downtime begins at the first missed heartbeat and clears when the next successful heartbeat arrives.Short local network interruptions can appear as a delayed status update rather than an immediate outage. Use the fault log and heartbeat history together when you investigate reliability.
Queued Device Jobs
Most changes are delivered as jobs. A service records the requested work, publishes it for the target site, and the router receives it when it checks in. Common job-producing actions include:- Running a scheduled script
- Requesting a fresh backup
- Applying control plane or security policy changes
- Updating VPN or WAN failover configuration
- Running ARP or inventory synchronization
- Hydrating an event-driven script into RouterOS commands
Live Commands
Some actions need current router state. Those use the management server connected to the site and run through the management tunnel. Use live commands when you need dynamic state such as current routes, active sessions, live interface data, or a direct operational check. Use backups when you need static configuration, because backup files are usually faster and more complete for reviewing installed configuration.Faults, Notifications, and Workflows
Faults are normalized operational events. Core site state and feature services publish events such as site offline, site online, WAN offline, WAN online, and WAN packet loss. SDX stores the fault state, sends it to the portal, and can route it to notifications and workflows. Notification groups decide who receives operational messages. Workflows can also subscribe to platform events, enrich context, call APIs, run scripts, tag resources, or trigger downstream workflows.Reports
SLA and vulnerability reports are generated from stored platform data. SLA reporting uses fault windows and optional business schedules. CVE reporting uses scan schedules, scan-site results, enrichment, and generated report artifacts. Because reports depend on stored data, fix data quality first:- Sites should have clear names and tags.
- Faults should be reviewed and acknowledged with useful context.
- Business schedules should match the service window you actually report against.
- Notification recipients should be maintained before reports are scheduled.
Practical Implications
Expect Asynchrony
A successful save in the portal often means SDX accepted the change. Device completion may happen later and should be checked through progress, logs, or site state.
Design for Rollback
Use backups, staged policy rollout, tags, and narrow site selections before making fleet-wide changes.
Use Tags Deliberately
Tags become operational routing data for reports, workflows, filtering, and ownership. Keep tag keys consistent.
Prefer Least Privilege
Roles, transient access, workflow authorizations, and vault secrets should grant the minimum access needed for the task.
Onboard Your First Router
Put the model into practice by creating a site and bringing a router online.