Getting Started

You’ve ordered a managed Uptime Kuma from server.camp — congratulations! Uptime Kuma monitors your websites, APIs, and servers around the clock and notifies you immediately when something goes down. This guide is written for freelancers, small and medium-sized businesses, and nonprofits that don’t want to hear from their customers or members that the website is down.

When your online shop, customer portal, or nonprofit website goes offline, every minute counts. Without monitoring, you find out only when a customer calls or a member writes — and by then, hours may have passed.

Uptime Kuma checks your services every minute and sends you a notification the moment something isn’t reachable — before anyone else notices.

Common use cases:

• Company website — is it publicly accessible?
• Online shop — does the homepage load? Is checkout reachable?
• Customer portal or SaaS app — around-the-clock monitoring with alerts on outages
• Email server — is the SMTP or IMAP service reachable?
• Internal systems — ERP, phone system, VPN endpoint, NAS
• SSL certificates — get notified before a certificate expires
• Cron jobs and backups — confirm that automated processes are running reliably
• Status page for customers or members — a public overview of current system status
• Database servers — query PostgreSQL, MySQL, MariaDB, MongoDB, Redis directly
• APIs — check JSON responses and evaluate their content

Uptime Kuma works with three central elements:

• Monitor — a monitoring rule (e.g. “Check URL X every 60 seconds”)
• Notification — where should alerts go when something fails? (Email, Mattermost, Telegram, SMS, etc.)
• Status page — a public or internal overview showing whether your services are running

Each monitor can be linked to multiple notifications. Set up notifications once and attach them to as many monitors as you like.

Single-user system

Uptime Kuma currently supports only one user. All monitors, notifications, and status pages are visible to that user. There’s no user management or roles — everyone with dashboard access sees and can edit all monitors. Share dashboard access deliberately and enable two-factor authentication.

1. Set up notifications — at minimum email, ideally a second channel too
2. Create your first monitor — e.g. your own website
3. Add more monitors — email server, APIs, internal systems
4. Assign tags — group monitors by customer, system, or priority
5. Set up a status page — for customers or internal transparency
6. Plan maintenance windows — for scheduled maintenance

Consider notification dependencies

For alerts to actually reach you during an outage, your notification methods shouldn’t depend on the systems being monitored. If you’re monitoring your email server with Uptime Kuma, don’t use that same email server as the notification channel — you won’t receive alerts if it goes down. A second channel like an external mail server, ntfy.sh, Telegram, or Mattermost is a good complement.

Uptime Kuma supports a wide range of monitor types. Here are the most important ones with practical examples:

Use IP allowlisting

It makes sense to restrict database access to the IP addresses of legitimate clients. This ensures that potential attackers can’t connect. Find the IP addresses used by server.camp in the documentation or ask our support team.

Which monitor type for which purpose?

For most SMBs, HTTP(S), TCP Port, Ping, and Push are enough. HTTP(S) for websites and APIs, TCP for mail servers and databases, Ping for servers and network devices, Push for cron jobs. Database monitors are worth it if you have direct database access and want to confirm they’re not just reachable but also functional.

1. Click “Add monitor” in Uptime Kuma
2. Choose a type (start with HTTP(S))
3. Enter a name (e.g. “Company website”)
4. Enter the URL (e.g. https://example.org)
5. Set the check interval — every 60 seconds is a good default
6. Configure retries — 2–3 is recommended to avoid false alarms from a single timeout
7. Link notifications (must be set up first)
8. Optionally: assign tags (e.g. “Production”, “Client A”)
9. Save

Uptime Kuma starts monitoring immediately. A green dot in the sidebar means everything is OK.

For HTTP(S) monitors, additional options are available:

• Accepted status codes — default is 200–299. Expand the range for redirects (301/302).
• Maximum redirects — how many redirects Uptime Kuma should follow
• HTTP method — GET (default), POST, PUT, HEAD
• HTTP headers and body — for APIs that require authentication
• Certificate expiry notification — warning X days before SSL expiry (e.g. 30 days)
• Upside-down mode — reverses the logic: alert when the service is reachable (useful for services that should be offline)

Under Settings → Notifications, configure where alerts should go. Uptime Kuma supports over 90 notification services. The most important:

1. Type: Email (SMTP)
2. Enter your email provider’s SMTP server (address, port, username, password)
3. Configure sender and recipient address
4. Test with “Test” to confirm the email arrives

If you use Mattermost at server.camp:

1. Type: Mattermost
2. In Mattermost: Integrations → Incoming webhooks → Create new webhook
3. Paste the webhook URL into Uptime Kuma
4. Optionally: configure the channel and display name

If you use ntfy.sh for push notifications:

1. Type: ntfy
2. Enter the server URL, e.g. https://ntfy.sh (or your self-hosted instance)
3. Set a topic — a freely chosen name, e.g. uptime-kuma-alerts
4. Optionally: configure priority and tags

Use ntfy.sh for free

ntfy.sh works for free, even without an account. Make your topic name unique and hard to guess so you don’t receive others’ notifications — e.g. uptime-kuma-yourname-51586451 or 25168168-yourname-alerts. A free push channel with no mix-ups.

Fast, reliable, and free — ideal as a second notification channel:

1. Type: Telegram
2. Create a bot: message @BotFather in Telegram → /newbot → copy the token
3. Get your chat ID: message the bot, then use the Telegram API to retrieve the chat ID
   • Example: https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates
   • The chat ID is in the response, e.g. "chat":{"id":123456789,"first_name":"Max","type":"private"}}
   • Here: 123456789
4. Enter the token and chat ID in Uptime Kuma

Set up at least two channels

Always set up at least two notification channels — e.g. email and Mattermost (or Telegram). If the email server itself has a problem, the second channel still reaches you. That’s exactly what monitoring is for: working even when something goes wrong.

Enable default notification

Mark a notification as “Default notification” and it’s automatically linked to every new monitor. Saves time and prevents accidentally setting up a monitor without any notification.

A simple HTTP check only verifies that a page responds. Sometimes a page responds with status code 200 (OK) but shows an error — e.g. “Database connection failed” or “Maintenance mode”.

A keyword monitor lets you check whether a specific text is present or absent on a page:

• Must be present: alert if e.g. your company name or “Welcome” doesn’t appear on the page
• Must not be present: alert if “Error”, “Fatal”, “Maintenance”, or “Downtime” appears

Practical examples:

For APIs that return JSON, use the HTTP(S) JSON Query monitor type to check specific values in the response.

Example: Your API responds to /api/health with:

{ "status": "ok", "database": "connected", "version": "2.1.0" }

• JSON Path: $.status
• Expected value: ok

Uptime Kuma alerts if the value of status is not ok — even if the API responds technically.

JSON query for microservices

If you run multiple microservices, set up a JSON query monitor on each service’s health endpoint. This tells you not just whether the service is reachable, but whether it’s working internally (database connection, external dependencies, etc.).

An expired SSL certificate marks your site as “insecure” for all visitors — a serious problem for customer trust and SEO.

Uptime Kuma can warn you automatically when a certificate expires in X days:

1. Set up an HTTP(S) monitor for the relevant domain
2. In monitor settings, enable “Certificate expiry notification”
3. Enter the warning threshold (recommended: 30 days)

Uptime Kuma checks the entire certificate including the certificate chain (CA certificates). This also catches problems with intermediate certificates.

Many organizations run automated processes: backups, database cleanups, invoice sending, data imports. When a cron job silently stops running, it often goes unnoticed for weeks.

A push monitor (heartbeat) reverses the principle: instead of Uptime Kuma querying a service, the service checks in with Uptime Kuma. If the check-in doesn’t arrive → alert.

1. Add monitor → type: Push
2. Enter the expected interval (e.g. 1440 minutes = once daily)
3. Uptime Kuma shows a push URL
4. Add a curl call to this URL at the end of your cron job:

# At the end of your backup script:
curl -s https://your-uptimekuma.srv.camp/api/push/abc123?status=up&msg=OK

Monitor every automated process

Set up a push monitor for every cron job, every backup script, and every automated process. The effort is minimal (one curl line at the end of the script), but the benefit is enormous: you’ll know immediately when a process stops running — instead of weeks later when the damage is already done.

As the number of monitors grows, tags help keep things organized. Tags are colored labels you can assign to monitors.

Useful tagging strategies:

Tags appear in the monitor overview and on status pages. Filter by tag to quickly see all monitors for a specific client or system type.

Uptime Kuma can create multiple status pages showing whether your services are up. This is especially useful when customers or members want to know if the website, shop, or customer portal is working right now.

Under Status pages → New:

1. Enter a title and description
2. Set the slug (determines the URL, e.g. /status/customers)
3. Upload a logo (optional)
4. Create groups — each group bundles related monitors (e.g. “Website”, “Email”, “API”)
5. Assign monitors to groups
6. Save and publish

Uptime Kuma supports unlimited status pages. This is especially useful when you want to serve different audiences with different information:

Transparency builds trust

Many organizations shy away from a public status page — but the opposite is true: customers appreciate transparency. A status page signals a professional approach to your infrastructure. And during an outage, customers can check for themselves instead of contacting support — taking pressure off your team.

• Logo and favicon — maintain your corporate design
• Description text — Markdown supported, e.g. for contact info or links
• Custom footer — legal notice, support contact
• Custom domain — status page accessible at status.example.org (Business and Corporate plans)

For scheduled maintenance (e.g. server updates, migrations), set up maintenance windows:

Under Maintenance → New:

1. Enter a title (e.g. “Server update February 2026”)
2. Define the time range (start and end time)
3. Choose a schedule:
   • One-time — for a planned maintenance event
   • Recurring — e.g. every Sunday 02:00–04:00 for automatic updates
4. Select the affected monitors
5. Save

During the maintenance window:

• No alerts are triggered for affected monitors
• The status page shows the maintenance status
• Uptime calculations are not negatively affected

Set up recurring maintenance windows

If you apply automatic updates regularly (e.g. Sunday nights), set up a recurring maintenance window. This avoids false alarms during the update phase and keeps your uptime statistics clean.

The Uptime Kuma dashboard shows at a glance:

• Current status of each monitor (green = OK, red = down, yellow = pending, grey = maintenance)
• Response time as a time-series chart — ideal for spotting performance issues before they cause an outage
• Uptime percentage across different time ranges (24h, 7 days, 30 days, 1 year)
• Certificate expiry — days until the SSL certificate expires
• Heartbeat bar — color-coded history of recent checks

The response time chart shows not just whether a service is reachable, but also how fast it responds. A slowing service is often an early indicator of upcoming issues:

• Rising response times → server under load, database problems, network bottleneck
• Erratic fluctuations → unstable connection or intermittent problems
• Sudden spike → current load, e.g. from a marketing campaign

Check response times regularly

Don’t just look at up/down status — also watch response times. If a website normally responds in 200ms and suddenly takes 2 seconds, something is wrong — even if it’s technically still reachable.

Your monitoring dashboard contains sensitive information about your infrastructure. Secure access with two-factor authentication:

Under Settings → Security → Two-factor authentication:

1. Enable 2FA
2. Scan the QR code with a TOTP app (Aegis, Google Authenticator, etc.)
3. Store backup tokens safely

Recommended monitors for freelancers:

• HTTP(S) monitor for every client website
• TCP monitor for every client mail server
• Push monitor for every backup script
• SSL certificate warning for all domains

Tip: Create a dedicated status page for each client with their logo. It signals professionalism and gives the client transparency about their systems at any time — a real differentiator.

Recommended monitors for SMBs:

• HTTP(S) + keyword for website and shop
• TCP for mail server, VPN endpoint, database
• Ping for servers, routers, NAS
• JSON query for APIs and health endpoints
• Push for backups, cron jobs, batch processes
• Database monitors (PostgreSQL/MySQL) where direct access is available

Tip: Set up a Mattermost channel “#monitoring” and connect it as a notification channel. The entire team sees issues immediately — reaction time drops dramatically.

Recommended monitors for nonprofits:

• HTTP(S) for nonprofit website and registration portals
• TCP for the nonprofit mail server
• SSL certificate warning for the nonprofit domain
• Optional: push monitor for member database backup

Tip: Share the status page with the board — during an outage, everyone can immediately see what’s happening without back-and-forth questions. Notifications via Telegram or email go to the 2–3 people who can take technical action.

Connect Uptime Kuma with Mattermost for real-time alerts in your team chat. When something goes down, the whole team sees the message immediately — with the monitor name, status, and duration.

Via REST API or webhooks, Uptime Kuma alerts can automatically create tickets in Zammad. Every outage is automatically captured as a ticket, assigned, and tracked — ideal for teams with structured incident management.

Via webhooks, Uptime Kuma can send events to Node-RED. There you can build complex automations — e.g. “When the shop monitor switches to ‘Down’ → send SMS to the CEO AND create a ticket in Zammad AND post a message in Mattermost.”

If you need help setting up monitors, notification channels, or status pages, reach out any time at support@server.camp.

Find answers to common questions on our product page.