Monitoring & Alerts
Watch your servers' health on one screen and hear about problems early
CPU, memory, disk and network charts, alerts, network flows and backup status sit together inside your cloud portal, with no agent installed on your servers.
Why now
- On Saturday night the database server's disk filled up, the application could no longer write, and nobody noticed until a customer complained on Monday. An alert in the team channel at eighty-five percent would have had it fixed on Friday afternoon.
- Users say the system is slow, but nobody knows which server is struggling or since when. Seven days of CPU and memory charts replace guesswork with data.
- Building a separate monitoring server, installing an agent on every machine and keeping it all current is too much for a small team. Here metrics are read from the infrastructure layer, and nothing is installed on your servers.
- Management asks how many more servers can be launched for a new project. A screen showing how full the quota is and roughly how many servers still fit answers that in a minute.
- One of your servers might be sending traffic to a country you've never done business with, and nobody would know. The network flows screen shows who talks to whom, on which port and with which country.
What changes
| Today | With Nesnet |
|---|---|
| You learn the disk is full from a customer, after the app has stopped. | When a threshold is crossed, an alert lands in your team's Slack channel or your incident system. |
| Monitoring needs its own server and an agent on every machine. | Metrics are read from the infrastructure layer; nothing is installed on your servers. |
| A short load spike floods you with alerts at midnight. | An alert fires only when the breach lasts for the duration you set. |
| Metrics, backup status and network traffic live in separate tools. | They all sit inside your cloud portal, in tabs of the same extension. |
| When a data source is unreachable, the screen still looks fine. | The screen says when the data was last updated and when a source can't be reached. |
From today to live: how it works
- 1
The monitoring tab appears in your portal
The monitoring extension comes ready in your organization's portal on Nesnet's cloud. CPU, memory, disk and network charts for your servers are visible from day one, with nothing for you to install.
- 2
Connect your notification channel
Add your team's Slack incoming webhook URL or your incident system's webhook URL as a notification channel. You define a channel once, and every alert can use it.
- 3
Write your first alert rules
Define rules for disk, CPU and memory by choosing the threshold, duration and severity. Starting the duration condition at a few minutes is a good way to avoid needless alerts from short spikes.
- 4
Follow quota, backup and network
Track quota usage, per-server backup status and network flows in tabs of the same extension. The health summary and the event timeline show you where to start when something goes wrong.
What you get
Every server's health on a chart
Each server's CPU and memory usage, root file system fill level, network traffic and running or stopped state are charted. Instead of guessing when a problem started, you see it on the line.
History from fifteen minutes to thirty days
Open the charts for the last fifteen minutes, an hour, a day, a week or thirty days. When someone complains about slowness, you compare yesterday, last week and last month on one screen.
Alert rules with your own thresholds
Write your own threshold for CPU, memory or disk with greater-than, greater-or-equal, less-than or less-or-equal comparisons. Rules are evaluated on the server, so a breach at night triggers a notification even when nobody has the portal open.
No noise from short spikes
A duration condition keeps an alert quiet unless the breach lasts without a break for the time you set. A backup job's few-second CPU spike won't wake your team, and when the breach ends the alert is recorded as resolved.
Three levels of severity
Give every alert an info, warning or critical severity. Your own incident system can route alerts by severity, sending one to a channel and a critical one to the phone of whoever is on duty.
Alerts land in your Slack channel
Alerts are sent to your team's Slack channel through an incoming webhook, so nobody has to watch a separate screen. The message says which server fired, with what value and when.
A webhook into your own system
The webhook body carries organization, rule name and ID, severity, state, affected object, measured value, message and time as structured JSON. Your incident tool, or your own email or SMS gateway, can process it directly.
Acknowledge a firing alert
Acknowledge a firing alert to show the team someone is on it. Alert history is kept for ninety days, so you can look back at how often a problem has happened before.
One event, one message
Even if the extension restarts, alerts that are already firing are remembered and not notified twice. Your team isn't buried under repeated messages for the same issue, and the channel stays quiet.
How full is your quota, how many servers still fit
See at a glance how much of your CPU, memory and storage quota is used and roughly how many more servers fit. When usage passes seventy percent, the screen tells you you're nearing the quota, so capacity requests don't wait until the last day.
Backup status in the same place
Each server's last successful backup time and whether it met its backup target also appear on the monitoring screen. The backup owner sees which server missed its target without opening another panel.
Who talks to whom: network flows
The network flows screen shows which server talks to which address, on which port and protocol, and whether the traffic was allowed. You notice an application connecting somewhere unexpected without reading log files.
The country your traffic goes to
Network flows also show which country the destination address is in. Seeing one of your servers talk to a country you never do business with can be the first clue of a security incident.
Failed sign-in warnings
Failed sign-in attempts from the last seven days stand out as a warning on the audit screen. You see that someone has been hammering an account without anyone opening a log file.
Pattern alerts on the audit trail
An alert fires when a given phrase appears a set number of times in the audit trail within the window you choose. For example, servers deleted one after another within an hour, or repeated permission changes, land in your team's channel.
A health summary at a glance
A single health verdict for your organization, a risk score and four summary cards sit on the home screen. In the morning meeting, the answer to whether the environment is okay is on one screen, along with where to look next.
A timeline of events
Metric, alert, network flow, audit and cost events line up in the same time window. You read on one line who changed what before an outage and when each value started to climb.
Screens that refresh themselves
Health, server, network and alert screens refresh every thirty seconds, and the others every minute. Refreshing pauses when the tab is hidden, so a screen left open doesn't create needless load.
Data freshness on every screen
Every screen shows how many seconds ago its data was updated and whether it is live, paused or stale. The risk of making a decision from an old chart is removed by the screen itself.
No separate panel, no separate password
Monitoring screens are embedded in the cloud portal where you create your servers. You don't open a second account for your team, define separate permissions or teach them another tool.
Why Nesnet
Nesnet's extension, inside the portal
The cloud portal doesn't offer tenants a monitoring screen on its own, so Nesnet closed the gap with an extension it wrote. Monitoring opens inside the portal where you manage your servers, not in a separate panel with a separate login.
No agents, no setup
Metrics are read from the virtualization layer's measurement services, so there are no agents to install or update and no monitoring server to run. A server you create shows up in the charts from its first minute.
A screen that never pretends
When a data source can't be reached, the screen doesn't show an empty or healthy-looking table; it says the source is temporarily unavailable. Every screen shows how many seconds ago the data was updated and whether it is live or stale.
No one else can see your data
Your organization's identity is taken from the authenticated portal session on every request, never from a request parameter. An alert rule is evaluated only against your own organization's servers.
Your data stays in Türkiye
Metrics, alert history and the audit trail stay in Türkiye, on Nesnet's infrastructure in the Equinix Istanbul (Dudullu) and Türk Telekom Ankara facilities. Monitoring data is never sent to a service abroad.
Run by Nesnet, supported locally
The same Nesnet team builds and runs the extension, the measurement sources and the cloud underneath. When you want to know why a chart or alert behaves the way it does, ask Nesnet’s support team, in Turkish or English.
Example scenarios
A disk caught before the weekend
Situation
Daily log files are slowly filling the disk of an e-commerce company's database server. Last year the disk filled up on a Saturday night, and orders stopped until Monday.
Outcome
The team set a critical alert for disk usage above eighty-five percent for ten minutes and connected it to their Slack channel. The warning arrived on Friday afternoon, old logs were cleared and the disk was grown.
Finding the source of slowness
Situation
Staff at an accounting firm say the system slows down in the last week of every month. The IT team doesn't know which server is struggling.
Outcome
The thirty-day chart showed the application server's memory hitting the ceiling during month-end batch jobs. The server's memory was increased and an alert rule was written for the same threshold.
Alerts wired into an incident tool
Situation
A software company collects all operational alerts in its own incident management tool and doesn't want alerts stranded on a separate screen.
Outcome
The monitoring webhook was connected to the incident tool, and the severity field in the JSON body routes critical alerts to a phone and the rest to the team channel. A resolved alert closes the incident in the tool on its own.
Traffic to an unfamiliar country
Situation
The security lead at a logistics company wants to see what a server that only serves customers in Türkiye is sending out.
Outcome
The network flows screen showed the server talking regularly to an address in an unexpected country. The source turned out to be a forgotten test tool; it was removed and an outbound firewall rule was added.
A capacity question for a new project
Situation
A software house's management asks how many more servers the current quota can hold for a new customer project.
Outcome
The quota screen showed memory quota at seventy-five percent and room for roughly four more mid-sized servers. A quota increase was requested before the project began.
Who does what
| Nesnet | You |
|---|---|
| Develops, runs and updates the monitoring extension. | Write your own alert rules, thresholds and severities. |
| Collects measurement data and network flow data from the virtualization layer. | Define your Slack channel or webhook URL as a notification channel and keep it working. |
| Evaluates alert rules continuously on the server side. | Handle incoming alerts and acknowledge firing ones. |
| Maintains organization isolation, so each organization sees only its own data. | Decide on adding resources or shrinking servers based on quota warnings. |
| Keeps alert history and the audit trail for ninety days. | Run your own monitoring tool on your servers if you need in-application metrics. |
Who it is for
IT teams running servers on Nesnet's cloud
Teams that want to know before a disk fills or a CPU hits its ceiling. Alert rules with your own threshold, duration and severity warn you before the problem reaches users.
Teams with an incident tool or a Slack channel
Teams that want alerts to flow into the incident management tool or team channel they already use. The webhook body is structured JSON, so your own system can process it easily.
Managers planning capacity
Managers who want to see how much of the quota is used and how many more servers fit. Once usage passes seventy percent, the screen warns you on its own.
Security and backup owners
People who want failed sign-in attempts, traffic leaving for the outside world and servers missing their backup target in one place. Each lives in its own tab of the same extension.
May not be the right fit
If you want alerts by email or SMS, this service won't cover it today; the notification channels are webhook and Slack. You can get email or SMS by connecting the webhook to your own notification system.
If you need synthetic checks that probe whether your website is reachable from outside, or in-application performance monitoring, this isn't that product; for those, running your own monitoring tool next to your servers is the better fit.
Under the hood
The monitoring screens are an add-on Nesnet developed for its cloud portal, and they open directly inside the tenant portal. The add-on reads VM metrics and network flows from the virtualisation layer's metrics services read-only and changes nothing there. Flows are filtered by your organisation's network segments, while alarm history, the audit trail and event data are stored in a database that ships with the add-on. Alarm rules are evaluated server-side, every 60 seconds by default, so they keep running whether or not anyone has the portal open. The portal, the metric sources, the network and the database are all parts of the same Nesnet cloud, run by the same team, which makes capacity decisions from its own measurements.
Building blocks
- Cloud portal
- the tenant portal; the monitoring screens open here under the same session
- Nesnet monitoring add-on
- charts, alarm rules, notifications, network flows, audit and backup views
- Metric and log collection layer
- source of VM metrics (5-minute collection interval)
- Network flow collection layer
- source of network flow data
- Software-defined network
- your organisation's network segments, used to scope flows
- Event database
- database for alarm history, the audit trail and event data
How it compares
| Option | When it is the right choice |
|---|---|
| Run your own monitoring server and agents | The right choice when you need in-app metrics, custom plug-ins or detailed counters from inside the operating system. The trade-off is that installing and updating agents and keeping the monitoring server alive become your team's job. The two approaches can also run side by side. |
| Rely on the portal's VM list alone | With a handful of VMs, where knowing whether each one is on or off is enough, you may not need another screen. It stops being enough the moment you want thresholds, history or notifications. |
Technical specifications
| Monitored values | CPU (%), memory (%), root file system fill (%), network throughput (KBps), running/stopped |
|---|---|
| Disk figure | fill percentage of the VM's root file system; no IOPS or latency |
| Source resolution | 5 minutes |
| Chart ranges | 15 min, 1 hour, 24 hours, 7 days, 30 days |
| Per chart | up to 50 VM series, up to 720 points per series |
| Screen refresh | health, VM, network and alarm views 30 s; audit, backup and timeline 60 s; paused while the tab is hidden |
| Agent | none; metrics come from the infrastructure layer |
| Evaluation interval | 60 seconds by default, server-side |
|---|---|
| Alarm metrics | CPU, memory, disk; >, ≥, <, ≤; customer-set threshold |
| Duration condition | no alarm unless the breach is sustained; resolved event when it clears |
| Severities | info, warning, critical |
| Channels | webhook (structured JSON), Slack incoming webhook |
| Webhook fields | organisation, rule name and ID, severity, state, object, value, message, time (RFC 3339) |
| Alarm history | 90 days |
| Tenant isolation | organisation taken from the authenticated portal session |
|---|---|
| Audit trail | 90 days |
| Failed sign-ins | last 7 days, flagged on the audit screen |
If something breaks
A data source goes down
The affected screen says the source is temporarily unreachable instead of showing an empty or clean table. A source that is temporarily unreachable is labelled differently from one that was never configured.
Responses slow down
The screen shows how long it has been waiting. After 45 seconds without an answer it shows an error with a retry button rather than spinning forever.
Nobody has the portal open
Alarm rules are evaluated on the server, not in the browser. A breach at night is caught and notified even if no one is watching.
An evaluation round fails
The error is logged and the rule is evaluated again in the next round. A single failed round does not take the alarm service down.
The add-on restarts
Alarms that were already firing are remembered and not sent a second time. Your team does not get duplicate messages for the same incident.
Frequently asked questions
Pricing and first steps
Pricing
Monitoring and Alerts is billed monthly. The price is set by the resources you use and the items you choose, and Nesnet’s team prepares your quote.
What the price depends on
- Monitored virtual servers: the number of VMs in your environment.
- Storage used: the space taken by your VM disks is measured in GB.
- Outbound traffic: data leaving your environment for the internet is measured in GB.
How to get started
- 1.Fill in the form or call 0800 606 1071.
- 2.We agree on the servers to watch and your alert channel in one call.
- 3.You write your first alert rule from the monitoring tab in your portal.
Hear about the problem before your customers do
Tell the Nesnet team which servers you want watched and where alerts should go, and you'll hear back within the same business day. With no agent and no extra panel, you write your first alert rule the same day.