## Introduction
Kenyan ISPs managing MikroTik routers need reliable ways to confirm device status without relying on guesswork or manual checks. CENTRANET provides documented capabilities for monitoring router health through automated discovery, heartbeat tracking, and configuration verification. This article explains how to use these features to maintain network visibility and reduce uncertainty in router operations.
## Router Discovery and Initial Visibility
The first step in monitoring router health is ensuring the device is discoverable within the CENTRANET workspace. According to the MikroTik provisioning guide, ISPs can link a router in the Router fleet section and choose either Automatic setup or Monitor existing setup. This process begins with discovery, where CENTRANET reads the router’s current configuration to identify internet, management, and customer connections. The system does not require opening public management ports, as the agent connects outbound to CENTRANET using standard enrollment. Once discovered, the router appears in the workspace with its basic identification, allowing ISPs to confirm it is reachable and responding.
## Heartbeat and Telemetry for Ongoing Monitoring
After enrollment, CENTRANET tracks router health through heartbeat and telemetry signals. As noted in the features documentation, ISPs can check the timestamp of a router’s authenticated heartbeat or agent contact to determine if it is actively communicating with the platform. This timestamp serves as a primary indicator of router availability and network connectivity. Telemetry data provides additional insight into recent device activity, helping ISPs distinguish between a temporarily unreachable device and one that is offline due to power, firmware, or configuration issues. These metrics are updated regularly and visible in the router’s detail view.
## Configuration Verification as a Health Indicator
Router health is not only about connectivity but also about whether the device is operating with the intended settings. CENTRANET supports configuration verification by reading back applied settings and comparing them to the approved plan. During provisioning, the system reports acknowledgements for each configuration step and shows waiting, recovery, and verification states to indicate progress. After setup, ISPs can review whether the router has successfully applied the approved Hotspot and PPPoE configuration. If configuration drift occurs, the system flags discrepancies, prompting a review rather than allowing assumptions about device state.
## Real Subscriber Journey Testing
To confirm that a router is not only connected and configured but also delivering service, CENTRANET recommends verifying a real subscriber journey. This involves connecting through a customer port, authenticating a test Hotspot or PPPoE account, and confirming DNS and internet browsing. For paid access, ISPs should verify provider configuration, conduct an agreed test transaction, check the payment record, and validate the router’s account-installation acknowledgement before testing browsing. This step separates configuration status from actual service delivery, preventing false positives when a router appears healthy but fails to authenticate users.
## Using Recovery Backups for Health Assessment
CENTRANET automatically creates a recovery backup before applying configuration changes. If a setup pauses or fails, ISPs can inspect the reported resource and latest device activity to understand what occurred. The system supports a read-only check via the "Check repaired step and continue" action, which verifies settings against the approved plan without making changes. Preserving the backup and management access allows ISPs to resume setup safely or discuss failures with support before resetting a customer-facing router. This approach reduces the risk of misdiagnosing configuration issues as hardware failures.
## Integrating Router Health into Support Workflows
Router health data from CENTRANET can be integrated into broader ISP operations. By keeping customer contact details, package assignment, and serving-router information together, support teams can quickly access invoice history and payment records when investigating service issues. Device evidence helps trace what happened after a service change was requested, such as a suspension or re-activation. This context prevents guesswork when determining whether an outage is due to router status, billing, or customer-side equipment.
## Conclusion
Kenyan ISPs can monitor MikroTik router health without guessing by using CENTRANET’s documented features: router discovery for initial visibility, heartbeat and telemetry for ongoing status, configuration verification for settings integrity, and real subscriber testing for service confirmation. Combined with recovery backups and integrated customer data, these capabilities provide a clear, evidence-based view of router operations. ISPs should treat each data point as part of a broader verification process, using timestamps, telemetry, configuration status, and test results together to assess health accurately.
Practical Health Checks for Daily Operations
ISPs should implement a daily verification routine using CENTRANET’s timestamp and telemetry data to detect early signs of router degradation. Begin by reviewing the heartbeat timestamp in the router detail view; if the last authenticated contact exceeds the expected interval—typically 5 minutes for active agents—flag the device for follow-up. Cross-reference this with telemetry trends: a sudden drop in reported signal strength or interface uptime, even if the heartbeat remains within bounds, may indicate intermittent power or link instability. For routers serving PPPoE customers, check the ‘last authentication’ timestamp alongside heartbeat data; a growing gap between the two suggests the agent is reachable but the PPP service is not responding. These checks should be logged in a simple spreadsheet or ticketing note, recording the timestamp, observed values, and any action taken, to build a baseline for each device over time.
Decision Examples for Common Scenarios
When a router shows a recent heartbeat but fails subscriber journey tests, ISPs should first verify configuration drift using the readback comparison tool in CENTRANET. If the Hotspot server profile or PPP secret does not match the approved plan, initiate a configuration verification cycle without applying changes—using the ‘Check repaired step and continue’ action—to confirm whether the discrepancy is due to a failed apply step or unauthorized local change. If the configuration matches but authentication still fails, inspect the telemetry for recent PPP interface resets or RADIUS timeout events; repeated failures here point to an upstream authentication server issue, not the router itself. In cases where the heartbeat is stale but the router responds to ping, use the outbound agent connection test: attempt to trigger a manual check-in via the RouterOS terminal command provided during enrollment, which forces the agent to reconnect and report status, helping distinguish between agent failure and network isolation.
Limitations and Mitigation Strategies
CENTRANET’s health monitoring relies on the agent’s ability to maintain an outbound HTTPS connection; if the router’s upstream ISP blocks port 443 or experiences DNS hijacking, heartbeat loss may occur despite the router being locally operational. To mitigate, ISPs should configure a secondary monitoring method—such as a local script that logs interface status and sends alerts via SMS or email when the agent has not checked in for twice the expected interval—without assuming CENTRANET is the sole source of truth. Additionally, configuration verification only reflects the last successful readback; if a change is made locally and then reverted before the next agent cycle, drift may go undetected. To address this, schedule a manual configuration audit weekly for high-risk routers, comparing the running config against the approved plan using the ‘Export compact’ feature in RouterOS and reviewing differences in a diff tool. Finally, real subscriber testing requires valid test credentials; ISPs must ensure test accounts are not subject to rate limiting or expiration during validation cycles, and should rotate credentials periodically to avoid lockout due to failed attempts.
Handover Records for Shift Transitions
Support teams should maintain a standardized handover log for router health investigations, capturing three key elements: the timestamp and value of the last heartbeat and telemetry reading, the outcome of the most recent configuration verification (including any discrepancies noted), and the result of the last subscriber journey test—specifically whether DNS resolution, authentication, and browsing succeeded. Each entry should include the technician’s initials, the router’s identifier, and a brief note on any environmental factors observed, such as recent power fluctuations or upstream maintenance. This record enables the next shift to quickly assess whether an issue is new, persistent, or resolving, reducing redundant checks and ensuring continuity. For example, a handover note might read: ‘Router MKT-042: heartbeat 10m ago (normal), telemetry shows 2 PPP resets in last hour, config matches plan, subscriber test failed at RADIUS step—escalated to auth server team.’ Such structured documentation turns reactive troubleshooting into a traceable, evidence-based process.
## References
- https://centranetispbilling.com/features
- https://centranetispbilling.com/docs/mikrotik-provisioning