Use cases

Mugnsoft is a distributed monitoring platform, but the fastest way to understand it is to see what teams actually do with it. Each use case below maps a real problem to the Mugnsoft components and monitor types that solve it.

The platform is built from four components — Webserver (central management and UI), Monitor probes (run the checks), Integrator (forward data out), and Sentinel Agent (host and process metrics). The scenarios below combine them in different ways. See Getting started for the underlying concepts.

1. Catch a customer-facing outage before your customers do

Problem. Your checkout flow breaks at 2 a.m. and you only find out when support tickets pile up the next morning.

With Mugnsoft. Record the full business transaction — log in, add to cart, pay — as an EUM (browser) monitor and schedule it every few minutes from one or more probes. When a step fails, the probe captures a screenshot, video, and HAR file, and the Webserver alerts your on-call channel immediately.

You use	For
EUM monitor	The multi-step browser scenario
Monitor probe(s)	Running the scenario on a schedule, close to the user
Alerting (Email / Slack / Teams / PagerDuty)	Notifying on-call the moment a step breaks

Because the scenario runs in a real browser, it measures what the customer experiences — not just whether a server is up. The screenshot and HAR capture turn “the site is down” into “the payment step timed out on this request.”

2. Monitor an API or website from several locations

Problem. The application is fast from your data center but slow for users in another region, and you cannot tell where the latency comes from.

With Mugnsoft. Deploy probes in each region and point the same URL or API monitor at the endpoint from every probe. The Webserver shows per-probe response time, so a regional slowdown is obvious. Add SSL-expiry and content-pattern checks so a certificate or a broken page never slips through.

You use	For
URL / API monitor	HTTP/HTTPS availability, response time, status code, content match
Multiple probes	Measuring from each location your users sit in
Certificate checks	Alerting before a TLS certificate expires

3. Watch the infrastructure underneath the application

Problem. The website is “up” but a database, cache, or network device behind it is degrading.

With Mugnsoft. Mix the lightweight protocol monitors to cover the stack: TCP for open ports, Ping for latency/jitter/packet loss, DNS for resolution, Database for query health, and SNMP for network gear. Group them so one red signal points straight at the failing layer.

You use	For
TCP / Ping / DNS monitors	Port, latency, and resolution health
Database monitor	Running a real query and validating the result (MySQL, MSSQL)
SNMP monitor	Polling switches, routers, and appliances

4. See the whole service as one status

Problem. A single service depends on a dozen monitors, and a wall of individual green/red lights does not tell you whether the service is healthy.

With Mugnsoft. Group related monitors into an Application. The Application rolls its members up into one aggregated status using a business rule, and renders the dependency graph in 2D and 3D. One glance answers “is the service healthy?” — then you drill down to the failing monitor.

You use	For
Applications	Aggregating many monitors into one business-level status
Dependency / 3D views	Seeing how components relate and where the red originates
Tags	Scoping each team to the applications they own

5. Publish a status dashboard without exposing the platform

Problem. You want partners or the public to see service health, but the monitoring console must stay on the internal network.

With Mugnsoft. Run a Webserver-Front replica in the DMZ. It receives a sanitized, read-only copy of the dashboards over a one-way encrypted channel and serves them to untrusted users — with no path back to the probes or any secret. Embed the App or 3D view straight into your own portal with a copy-paste iframe.

You use	For
Webserver-Front	A read-only DMZ dashboard host, no license needed
Dashboard embedding	Dropping a live status view into a custom portal

6. Stop alert noise during planned maintenance

Problem. A scheduled deployment fires dozens of false alerts every week and trains the team to ignore them.

With Mugnsoft. Define a Downtime window — once or on a recurring cron schedule — over the affected tags. Monitors pause and alerting is suppressed for the window, then resume automatically. No more 2 a.m. pages for a planned restart.

You use	For
Downtimes	Suppressing alerts during planned maintenance
Tags	Targeting exactly the monitors a change affects

7. Feed monitoring data into your existing stack

Problem. You already run Grafana, Splunk, or Elastic and want Mugnsoft’s results alongside the rest of your observability data.

With Mugnsoft. Point an Integrator at your downstream systems. It forwards monitoring results to InfluxDB, Splunk, Elasticsearch, Kafka, Zabbix, and more, so you can build dashboards and correlations in the tools you already use. See the Integration guides.

You use	For
Integrator	High-throughput forwarding to third-party systems
Integration guides	Wiring up Grafana, Splunk, Elastic, InfluxDB, Zabbix

8. Automate monitoring as code

Problem. You spin services up and down constantly and cannot click through a UI to create monitors each time.

With Mugnsoft. Everything in the UI is backed by the REST API. Generate a long-lived API key and create, update, or delete monitors from your CI/CD pipeline or an infrastructure-as-code workflow — so monitoring is provisioned with the service it watches. See API usage recipes.

You use	For
REST API + API keys	Programmatic monitor lifecycle management
API usage recipes	Ready-made automation workflows