GLWS · Monitoring
Check service availability and organise notifications through a self-hosted monitoring dashboard.
Common uses of Uptime Kuma.
Monitoring can only observe services reachable from its host. Keep a separate check outside the infrastructure you want to monitor.
Planning examples, not official minimum requirements.
Monitoring
Check the current supported operating systems, deployment methods, dependencies and licence terms. What you need depends on your workload, not just the application's name.
Large datasets and busy workloads can need far more memory, storage or different hardware. Any external API or service subscriptions are separate.
Read the Uptime Kuma documentation ↗ (opens in a new tab)Advice specific to this application.
An HTTP response, a reachable TCP port and a successful application transaction answer different questions. Match checks to the failures you care about and choose intervals that avoid unnecessary load. Configure notification destinations and test that alerts reach the intended person.
A monitor on the same server as the application can disappear during the same outage. Use an independent vantage point for important availability checks. Back up monitor definitions and settings, and decide what operational detail belongs on a public status page.
Linux guides that help with this setup.
Separate interface, routing, name-resolution, and listening-port problems without changing your server's network configuration.
Read guide →Allow the SSH port you actually use before enabling UFW or firewalld, then test access from another terminal.
Read guide →Create a compressed archive of your own project, verify it, and extract a test copy without overwriting the original files.
Read guide →Four steps that make the environment easier to maintain.
Read the publisher's instructions and choose a supported installation method.
Protect the dashboard, credentials and network endpoints before you expose any service.
Work out where the application keeps its state and store it separately from replaceable runtime files.
Back up the data and configuration, then check that you can restore them.
Run through it before and after you install.
$ application-checklist --name uptime-kuma
[ ] Supported deployment method
[ ] Authentication and access restrictions
[ ] Independent data backup
[ ] Updates and restoration tested
root@glws:~#
Quick answers before you choose resources.
No. The configurator only saves your application preference. It does not connect to any infrastructure or run an installer.
Use the planning example as a starting point only. Check the publisher's requirements and measure the whole stack under a realistic workload.
You do. Self-hosted applications need updates, configuration and recovery planning from the operator. The publisher's documentation describes supported maintenance.
The knowledge base covers Linux access, packages, services, firewalls and backups.
Other tools you might run alongside or instead.
Turn metrics and logs from connected data sources into dashboards for your services.
Explore application →Collect time-series metrics and query the behaviour of your infrastructure and applications.
Explore application →Website, email, DNS and database management in a hosting dashboard.
Explore application →A self-hosted assistant for connecting model-powered tasks with tools and messaging.
Explore application →