Software rarely fails at a convenient moment. A server runs out of memory after the team has gone home. An application slows down while customers are trying to check out. A database crosses a capacity threshold on a public holiday. By the time somebody notices, the system has already been telling a story for hours — in metrics, logs and resource signals that nobody was watching closely enough.
Excentry is built to make that story visible, and to make the important parts actionable. It is Observability as a Service and Notification as a Service in one place: monitor the systems your business depends on, define the thresholds that matter, and notify the people responsible for responding.
From scattered signals to one view
The first problem with monitoring is not a lack of data. Modern systems produce plenty of it. The problem is that the data is spread across server tools, application dashboards, database consoles and mobile platforms — each with its own account, terminology and alert settings.
Excentry brings those surfaces together. From one account, teams can monitor servers, web applications, databases and mobile apps. A real-time dashboard gives a current view of CPU, memory, network and application performance across the devices under management.
That shared view changes the first question in an incident. Instead of asking, "Which tool should I open?", the team can ask, "What is happening across the system?" A single service may look healthy at the application layer while its host is approaching a resource limit. A mobile release may be working for most users while one dependent API is degrading. The value of an observability platform is not another graph; it is the context around the graph.
Alert on what matters
Visibility is useful, but a dashboard still depends on somebody opening it. Excentry lets you set custom thresholds for the signals that matter to your operation. Alert when a resource crosses a critical limit, when application performance changes, or when a condition you care about needs attention.
The important word is custom. Every organisation has a different definition of a critical event. A development environment can tolerate a burst that would be urgent in production. A database may need a lower capacity threshold than a stateless web node. A mobile application may need an alert around service availability rather than server CPU.
Good alerting is therefore not about producing the most notifications. It is about creating notifications that are specific enough to prompt a useful response. Set the thresholds, reduce the noise, and make the signal reach the team before a customer has to report the problem.
SMS when the team needs to know now
Excentry currently supports SMS notifications for the moments when an inbox is not enough. An on-call engineer may be away from a laptop. A critical event may happen between shifts. A team may need a direct channel for a one-time passcode or an important transactional message. SMS is not a replacement for every notification, but it is a valuable escalation path when time and attention matter.
The same capability is available for application-driven messaging. Through an API, an application can request SMS delivery for one-time passwords and transactional messages, while Excentry handles the notification service behind that request. This gives teams a practical channel without requiring them to build carrier integration, delivery handling and operational tooling from scratch.
Email notifications are coming in January 2027. That gives teams another natural delivery channel for routine alerts, summaries and events that do not require the immediacy of an SMS. Together, email and SMS let notification policy match the urgency of the event: a message can go to an inbox for ordinary operational awareness, or reach a phone when the response window is short.
Powered by Redstone iPaaS
Excentry is powered by Redstone iPaaS, Nutworkz's integration and application platform. That relationship matters because observability is only half of the job. The other half is moving a trusted signal through a reliable process: identify the event, apply the right rules, deliver the notification, and keep enough context for the team to understand what happened.
Redstone provides the foundation for those processes. Its workflow and integration capabilities connect the monitored systems to the notification paths around them. Its API surface gives applications a way to request notification services. Authentication, permissions, logging and auditability remain part of the same platform rather than being stitched together as separate operational concerns.
It also means Excentry can fit into the way an organisation already runs. Redstone is designed to run on-premise, in a customer's cloud tenancy or in an air-gapped environment, depending on the deployment and security requirements. The platform can connect existing systems and workflows instead of asking every team to replace them before it can start monitoring.
There is a useful feedback loop here, too. Nutworkz runs its own systems on Redstone and uses Excentry to monitor them. Excentry is not a dashboard designed in isolation and then handed to a customer; it is part of the same product family, used in the environment where it was built. The monitoring service watches the platform that powers the monitoring service. That makes the product's promise concrete: signals, workflows and notifications are all expected to work in production.
Built for the whole stack
A system is rarely just a server. It is a chain of dependencies: infrastructure, databases, web applications, mobile clients, APIs and the people who respond when something changes. Monitoring only one layer leaves blind spots. Excentry's full-stack coverage is intended to give teams one operational starting point across that chain.
It is also designed to be quick to adopt. As a service, Excentry does not ask a team to install and maintain a separate on-premise monitoring tool before it can see value. Add the devices and applications that matter, define the thresholds, and build an alerting policy around the way the team actually works.
That makes Excentry useful at several stages of growth. A small team can start with the production systems that cannot go unnoticed. A growing organisation can bring more devices and services under one account. A larger operation can use it as a common view across teams, with notifications routed according to the urgency and ownership of each event.
Monitoring should lead to a response
Observability without notification leaves somebody responsible for watching a screen. Notification without observability sends messages without enough context to act. Excentry combines the two: a live view of system health, custom thresholds for meaningful events, and delivery channels that can bring those events to the people and applications that need them.
With SMS available today and email scheduled for January 2027, Excentry gives teams a focused way to move from reacting to reported problems to responding to known signals. And because it is powered by Redstone iPaaS, the service sits on the same integration, workflow and governance foundation Nutworkz uses to build and run its other products.
The goal is simple: know what is happening, know when it matters, and make sure the right response can begin without waiting for somebody to notice.
Explore Excentry or talk to our team about the systems you need to monitor and the notification paths your operation requires.