Why Didn't You See the Hosting Renewal Notification and Your Service Got Suspended?
Your service was suspended at 3 AM. Not because of an attack or a configuration error, but for the simple reason that the renewal notification ended up in the spam folder, and you thought automatic payment was active. We see this scenario in ServerNet support several times a week. The problem isn't memory or CPU; it's notification settings that were never taken seriously.
The ServerNet user panel sends a separate notification for each event. Renewal, invoice issuance, service status changes, payment errors. Each of these carries a different weight, and each should arrive through a different channel. If you manage them all with a single policy, you'll either lose critical alerts or get tired of unnecessary emails and ignore them all.
Three Categories of Notifications That Shouldn't Be Mixed Together
The first step in setting up notifications is classifying events. Not based on the title the system gives them, but based on the cost of ignoring them. We have three categories:
- Critical alerts: Service outage, suspension, repeated payment errors. Cost of ignoring: data loss or complete service downtime.
- Financial reminders: Renewal notifications, invoice issuance, approaching expiration dates. Cost of ignoring: scheduled downtime that could have been prevented.
- Routine announcements: Plan changes, infrastructure updates, product news. Cost of ignoring: almost zero.
Most users see all three categories in a single email inbox and then wonder why they missed the renewal notification. Because it got lost among 40 news emails. This is where they make a mistake: they assume the system will figure out what's "important" on its own. It won't. Determining importance is up to you.
Choose the Delivery Channel Based on the Cost of Ignoring
Email arrives for all three categories. But for the first and second categories, email isn't the only option. There's also SMS and in-panel notifications. My rule is this: any event that causes loss if left unseen for 24 hours should have at least two channels. Send the renewal notification by email and also send an SMS. Do the same for service outages.
For the third category, email alone is sufficient. If you send SMS messages for product news too, after two weeks you'll see those SMS messages as spam and block the entire number. Then on the day there's a real outage, the SMS won't reach you.
Configuring Renewal Notifications: Where 90% of Errors Occur
In the user panel, under notification settings, there's an option for "renewal reminder." Three time frames can be selected: 7 days, 3 days, and 1 day before expiration. The system default is set to 7 days. Don't change this. You might think 7 days is too early and you'll forget. Quite the opposite. When you see the 7-day notification, if you don't pay right away, the 3-day notification will come again. This is a deliberate design: three reminders, not one.
The problem I've seen many times is that users disable the "renewal reminder" option because they think they have automatic payment. Then automatic payment fails due to a card expiration, and no notification arrives either. Result: suspended service. If you have automatic payment enabled, don't disable the renewal notification. Leave it right there. One extra email per month is a small price to pay for the assurance that your service stays alive.
Separate Invoices from Email
The invoice issuance notification usually arrives at the same time as the renewal notification. But don't treat them as the same thing. An invoice is a financial document and needs to be searchable. If you use email filters, create a separate label for invoice@servernet.cloud. You don't do this in the notification settings; it's done in your email client. But if you don't, six months later you'll be searching for an invoice for your accounting and won't find it.
Take Service Status Seriously, Not Just Email
The user panel has a "service status" section that shows three states: active, suspended, and cancelled. Many users don't check this section until an outage email arrives. That's a mistake. If you're unsure whether your service is working properly, check the panel first, then email. The panel is always up to date; email might be delayed or land in spam.
Read the exact meaning of each of these states and the difference between "suspended" and "cancelled" in the documentation Understanding Service States in the User Panel. Take this seriously because many users think a suspended service means their data has been deleted and they panic. In reality, it's just a late payment that can be restored with a single settlement.
Outage and Incident Notifications: A Second Channel Is Mandatory
Don't rely on email alone for service outage notifications. Your server's email might be hosted on the very server that's down. This is a logical problem: a server that is down can't tell you it's down. For this reason, outage notifications must come through a channel that isn't dependent on your server. SMS or in-panel notifications (when you log in from another device) are the right options.
In notification settings, enable the "incident notification via SMS" option. Yes, it might only be used twice a year. Yes, you'll pay for the SMS. But a single 4-hour outage that you find out about 2 hours after it started costs more than a hundred years of SMS messages. Take this from someone who has managed production services for years.
This Is Where They Go Wrong: Turning Off All Notifications
The most common error I see in notification settings is this: a user who's tired of the number of ServerNet emails disables all notifications. A few weeks later their service gets suspended and they contact support asking, "Why didn't you tell me?" The answer is: we did, but you closed the channel. The notification system is a tool; if you turn it all off, you've blinded yourself. Instead of disabling everything, turn off the third category (routine announcements) and keep the first two.
Know the Support Scope to Interpret Notifications Correctly
A point few people think about: the notifications you receive from ServerNet only cover events related to your service. If your website is down but no notification has arrived, it means the problem isn't on ServerNet's infrastructure side. The issue is in your code, DNS, or third-party services. In that case, no notification will come, and none should come. To diagnose these cases, read the documentation Support Scope: What Exactly Is Covered? to know what's our responsibility and what's yours.
Knowing this boundary prevents two mistakes: one is contacting support unnecessarily when the problem is on your side, and the other is expecting a notification for something outside the service scope.
A Quick Decision-Making Table
| Event Type | Recommended Channel | Is Disabling Allowed? |
|---|---|---|
| Service outage | Email + SMS | No |
| Renewal notification | Email + SMS | No |
| Invoice issuance | No (it's a financial document) | |
| Payment error | Email + SMS | No |
| Plan change | Yes | |
| Product news | Yes |
Use this table as your default. If you have special circumstances, you can change it. But every change should be based on a reason, not on impatience.
Service Selection Also Affects the Number of Notifications
A point that gets less attention: the type of service you've purchased determines how many notifications are meaningful. If you have shared Linux hosting, notifications about resource usage are usually less important to you because resource management is on us. But if you have a virtual or dedicated server, CPU and disk usage notifications become critical because the responsibility is yours. In Service Comparison: Linux Hosting, Cloud Server, and Dedicated Server, you can see what responsibility boundary each one has, and then decide which notifications matter to you.
If you're still not sure which service suits your needs, read The Service Selection Guide. Choosing the right service reduces the number of irrelevant notifications, and then setting up notifications becomes simpler.
Take the Welcome Email Seriously
When you purchase a new service, you receive a welcome email that includes panel login information, default settings, and important links. Most users read this email and delete it. Mistake. In The Guide to Reading Your Welcome Email, it explains which settings you should change right there. One of them is precisely notification settings. If you set up the channels correctly on the first day, you won't have to search for settings in the middle of a crisis later.
Frequently Asked Questions
Why didn't I receive the renewal notification?
The most likely reason is that the email went to the spam folder or your email filter deleted it. Add the sender address to your whitelist and enable the SMS option in the panel's notification settings. If the service has already been suspended, first check the status in the panel, then contact support.
Can I disable news notifications but keep the renewal notification?
Yes. In the notification settings section of the panel, each category can be managed separately. Disable the "product announcements" category and keep the "renewal" and "incident" categories enabled. This is exactly the separation described in this article.
Does SMS notification have a separate cost?
Yes, sending an SMS for each event has an independent cost that is calculated in your invoice. But for critical events like service outages and payment errors, this negligible cost is nothing compared to the cost of service downtime. If you want to enable SMS for only one category, that category should be "renewal."
If automatic payment is active, is a renewal notification still necessary?
Yes. Automatic payment can fail for various reasons: card expiration, insufficient funds, or a gateway error. In this case, the renewal notification is the only alert that tells you something went wrong. Don't disable it.