A VPS running WordPress
PHP-FPM stops after an update and visitors see “502 Bad Gateway”. The alert names the service, and LayerAssist finds the setting the update changed.
Know when a service on your server stops.
Your website depends on a handful of services: the web server, the database, PHP, mail. LayerAssist watches the one you choose and tells you in plain words when it stops, and why.
At a glance
- Built-in monitorA built-in monitor checks over SSH that a service you name is running, on Linux and on Windows servers.
- Built-in monitorWhen it stops, you’re alerted and LayerAssist reads its logs to find out why. With “Fix safely” it starts the service again by itself; a full restart or a settings change waits for your OK.
- In chatIn chat, it restarts the service, finds what made it stop and fixes the cause where it can.
- Not available yetThe built-in monitor watches one service per server. Other services can be covered by a check of your own.
One stopped service can take your whole site down
A website isn’t one program. The web server answers visitors, PHP runs the site’s code, the database holds its content and a mail service sends its messages. If any one of them stops, the site breaks, often with an error that doesn’t say which.
Services stop for ordinary reasons: an update that changed a setting, a server that ran out of memory, a reboot that didn’t bring everything back. Knowing which service stopped, and why, is most of the fix.
Signs a service has stopped
- “502 Bad Gateway” or “503 Service Unavailable”
- “Error establishing a database connection”
- The site works, but its emails are never sent
- Everything broke after a server reboot or update
Why server services stop
Running out of memory
When memory runs out, the system stops the largest process, often the database. It happens at traffic peaks or with settings that ask for too much.
A settings error after an update
A package update or a manual change can leave a setting the service rejects, so it refuses to start.
Not set to start after a reboot
A service that isn’t enabled at boot stays down after the server restarts.
A full disk or a crash
No disk space, a damaged file or a bug can make a service exit and stay down.
How LayerAssist watches your services
You name the service once. LayerAssist checks it and, if it stops, starts with the most useful question: why?
Checks the service itself
Over SSH, on your schedule, it asks the server whether the service is running: systemd or the classic service tool on Linux, the service manager on Windows.
Alerts you once
One alert when the service stops and one when it runs again, in the app and by email.
Reads the logs
It looks at the service’s recent log entries and the system log to see what stopped it: memory, settings, disk or a crash.
Brings it back and fixes the cause
With “Fix safely” it starts a stopped service by itself. In chat it can also restart it and correct the setting or limit behind the failure.
Example: the database that kept stopping
What it checks
- MariaDB: stopped at 02:41
- Disk space: 52% used
- System log: the server ran out of memory and the system stopped the database
- Cause: database memory settings larger than the server’s 2 GB of RAM
What it changes
Lowered the database memory settings to fit the server, started MariaDB and enabled it at boot
What you get
- You know which service stopped, not just that the site broke
- The reason it stopped, from its own logs
- Stopped services started again, with the cause fixed
- Works on Linux and Windows servers
Real situations
A server with a background worker
A queue worker or a bot runs as a service. When it stops, nothing visibly breaks — until orders pile up. The service monitor catches it at once.
A Windows server
An app runs as a Windows service on a small business server. LayerAssist checks it over OpenSSH and tells the owner when it stops.
How to set up server service monitoring
Connect the server over SSH
Add the server in Sites & servers with its SSH login (OpenSSH on Windows).
Name the service to watch
In Automations, choose New automation, pick the server, select “Service health” and type the service name, for example nginx, mariadb or php8.2-fpm.
Choose how often
Every 5 minutes for an essential service, or less often for one that can wait.
Start with the service that matters most
The built-in monitor watches one service per server: usually the database or the web server. Cover others with a regular check as your own automation.
Questions about server service monitoring
Any service your server runs by name: web servers like Nginx, Apache or LiteSpeed, databases like MySQL, MariaDB or PostgreSQL, PHP-FPM, mail services or your own app. On Windows, any Windows service.
With “Fix safely”, it starts a stopped service by itself. A full restart or a settings change in an automatic run waits for your OK. In chat, ask and it does it straight away.
The built-in monitor watches one service per server. For more, ask LayerAssist for a regular check as your own automation; how often it can run depends on your plan.
Checking whether a service runs works with a normal SSH login. Reading system logs and restarting services usually need sudo or root, which is included from the Plus plan.
Related guides
- Built-in monitorWebsite availabilityAlerts you when your site stops answering, then looks into why.
- Built-in monitorDisk spaceWarns before a server disk fills up, and frees space safely.
- AutomationDatabase healthChecks your database is running, reachable and free of errors.
All monitoring guidesSee what each plan includesHow LayerAssist works
From $9 a month · 14 days to change your mind
Next time something breaks, you’ll know who to ask.
Add your website and ask your first question today. Not for you? Cancel within 14 days to get your first payment back, minus only the AI work you used.
Free for 7 days · No credit card needed · No technical knowledge needed.