Read the service failure
Read the real systemd unit state and time-matched journal before restarting it. A failed unit alone does not prove why the website failed.
A systemd unit may fail to start, stop later or run while its application cannot answer. This read-only first check requires authorised guest access; a managed application owner can pass the evidence to the OS operator. Check service scope before opening a shell or changing a unit.
Record the first failure time with its time zone, affected hostname or task, last known working time and any recent deployment or reboot. Do not restart or enable a service simply to clear a red status: that can hide the first error, repeat an unsafe job or interrupt another application.
Find the actual unit, not a guessed service name
Use the service name from your deployment record or ask the operator. The names myapp.service below are placeholders, not Novasean service names. On a system using systemd, an authorised administrator can run systemctl list-units --type=service --state=failed --no-pager to see currently failed service units, then systemctl status myapp.service --no-pager for the specific unit. A zero-row failed list does not prove the application works: the relevant unit may be inactive, have recovered, be socket-activated or run outside the system service manager.
If the named unit is “not-found”, verify the exact unit name and whether this is a system service, a user service, a container service or a provider-managed component. Do not create a new unit or try random service names during an incident.
Read Loaded, Active and the reported failure separately
In systemctl status myapp.service --no-pager, Loaded describes whether systemd could load the unit definition and may show its file and enablement state. Active shows the current high-level state: active, inactive, failed or a transition. A failed state can preserve the result of a process exit, timeout or restart limit. Note the displayed result, exit status, main process and “since” time, then compare that time with the customer-visible incident. An old failed state may be unrelated to a new outage.
systemctl is-enabled myapp.service answers an enablement question, not whether the service is responding now. A service can be active but not enabled for boot, or enabled yet failed. Some units are static, generated or activated by another unit. Do not change enablement on the basis of one status line. Even an “active (running)” process needs an application-level check, such as a safe health endpoint or a known request, before calling the service healthy.
Read the unit journal around the incident
The short log excerpt in systemctl status may not contain the first relevant error. Where your role has journal-read permission, use journalctl -u myapp.service -b --since "2026-10-12 01:00:00" --no-pager with the actual incident time in the server’s time zone. The -u filter includes messages about the unit, -b limits the current boot, and --since narrows the interval. If the failure occurred before a reboot, check journalctl -u myapp.service -b -1 --no-pager only if an earlier boot journal is retained. Missing previous-boot entries can reflect journal storage or retention, not proof that the service had no failure.
Look for the first meaningful error before a cascade of retries: a missing configuration file, permission refusal, dependency failure, exhausted storage, timeout or application exception. Treat a log line as evidence to investigate, not as authority to delete a file, weaken permissions or change a unit. Journal output can contain paths, tokens, addresses and private application data; redact it before sharing and use the authenticated support channel.
Illustrative check: a unit reports failed at 14:20, but its journal shows a configuration error at 14:19. Preserve both timestamps before the owner fixes that configuration and retests.
If the journal has no prior-boot records, state that evidence gap; do not infer that the service had no earlier failure.
Correlate one cause and choose the right owner
Compare the service-state time, journal error and the failing customer task. If the unit is active but requests fail, check the application path or gateway separately. If it failed after a deployment, the application owner can review the release and its safe rollback. If the error indicates disk pressure, use the related disk guide. A managed-VPS customer should send the unit name, state, incident time, redacted first error and affected task to the operator; the operator decides whether to change guest services under the agreed scope.
After an authorised repair, repeat the same status, journal-window and application-level check. Record whether the service remains healthy rather than treating one successful start as resolution. Avoid systemctl reset-failed before evidence is captured: that clears the failed-state record without fixing the underlying problem.
Common questions
Does “enabled” mean the service is running? No. It describes activation configuration, not current health.
Does “active” prove my website works? No. Test the actual application route and dependencies.
Why is the previous boot missing from the journal? Journal storage or retention may not include it. Ask the operator for its logging source rather than assuming no error occurred.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.