{"id":4701,"date":"2026-02-07T18:03:02","date_gmt":"2026-02-07T15:03:02","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/set-up-your-own-status-page-with-uptime-kuma-for-reliable-uptime-monitoring\/"},"modified":"2026-02-07T18:03:02","modified_gmt":"2026-02-07T15:03:02","slug":"set-up-your-own-status-page-with-uptime-kuma-for-reliable-uptime-monitoring","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/set-up-your-own-status-page-with-uptime-kuma-for-reliable-uptime-monitoring\/","title":{"rendered":"Set Up Your Own Status Page with Uptime Kuma for Reliable Uptime Monitoring"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Monitoring whether your website, API or store is really online is only half of the story. When something goes wrong, customers want a clear, always-available source of truth: a status page that shows current uptime, incident details and maintenance plans. In many teams this starts as a simple question in a planning or architecture meeting: \u201cWhere will we show outages and maintenance so everyone sees the same information?\u201d In this article we will walk through how to answer that question by deploying your own status page with <strong>Uptime Kuma<\/strong> and combining it with solid uptime monitoring and communication practices. We will focus on practical, self-hosted setups you can run on a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> or colocation machine at dchost.com, so you fully control your data, branding and notifications.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_a_Dedicated_Status_Page_Matters_More_Than_an_Error_Message\"><span class=\"toc_number toc_depth_1\">1<\/span> Why a Dedicated Status Page Matters More Than an Error Message<\/a><\/li><li><a href=\"#The_Building_Blocks_of_an_Uptime_Status_Stack\"><span class=\"toc_number toc_depth_1\">2<\/span> The Building Blocks of an Uptime &amp; Status Stack<\/a><\/li><li><a href=\"#What_Is_Uptime_Kuma_and_Why_Do_We_Like_It\"><span class=\"toc_number toc_depth_1\">3<\/span> What Is Uptime Kuma and Why Do We Like It?<\/a><\/li><li><a href=\"#Choosing_Where_to_Host_Your_Uptime_Kuma_Instance\"><span class=\"toc_number toc_depth_1\">4<\/span> Choosing Where to Host Your Uptime Kuma Instance<\/a><ul><li><a href=\"#Basic_Sizing_Guidelines\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Basic Sizing Guidelines<\/a><\/li><\/ul><\/li><li><a href=\"#Installing_Uptime_Kuma_on_a_VPS_or_Dedicated_Server\"><span class=\"toc_number toc_depth_1\">5<\/span> Installing Uptime Kuma on a VPS or Dedicated Server<\/a><ul><li><a href=\"#Option_1_Install_Uptime_Kuma_with_Docker\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Option 1: Install Uptime Kuma with Docker<\/a><ul><li><a href=\"#1_Install_Docker\"><span class=\"toc_number toc_depth_3\">5.1.1<\/span> 1. Install Docker<\/a><\/li><li><a href=\"#2_Create_Directories_for_Uptime_Kuma\"><span class=\"toc_number toc_depth_3\">5.1.2<\/span> 2. Create Directories for Uptime Kuma<\/a><\/li><li><a href=\"#3_Create_a_docker-composeyml\"><span class=\"toc_number toc_depth_3\">5.1.3<\/span> 3. Create a docker-compose.yml<\/a><\/li><li><a href=\"#4_Start_Uptime_Kuma\"><span class=\"toc_number toc_depth_3\">5.1.4<\/span> 4. Start Uptime Kuma<\/a><\/li><\/ul><\/li><li><a href=\"#Option_2_Install_Uptime_Kuma_Without_Docker_Nodejs\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Option 2: Install Uptime Kuma Without Docker (Node.js)<\/a><\/li><\/ul><\/li><li><a href=\"#Putting_Uptime_Kuma_Behind_HTTPS_with_a_Reverse_Proxy\"><span class=\"toc_number toc_depth_1\">6<\/span> Putting Uptime Kuma Behind HTTPS with a Reverse Proxy<\/a><ul><li><a href=\"#Example_Nginx_Reverse_Proxy\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Example Nginx Reverse Proxy<\/a><\/li><\/ul><\/li><li><a href=\"#Configuring_Monitors_and_Status_Pages_in_Uptime_Kuma\"><span class=\"toc_number toc_depth_1\">7<\/span> Configuring Monitors and Status Pages in Uptime Kuma<\/a><ul><li><a href=\"#Step_1_Create_Your_First_Monitors\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Step 1: Create Your First Monitors<\/a><\/li><li><a href=\"#Step_2_Set_Up_Notifications\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Step 2: Set Up Notifications<\/a><\/li><li><a href=\"#Step_3_Build_a_Public_Status_Page\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Step 3: Build a Public Status Page<\/a><\/li><\/ul><\/li><li><a href=\"#Designing_Clear_Incident_and_Maintenance_Communication\"><span class=\"toc_number toc_depth_1\">8<\/span> Designing Clear Incident and Maintenance Communication<\/a><ul><li><a href=\"#Incident_Lifecycle_on_Your_Status_Page\"><span class=\"toc_number toc_depth_2\">8.1<\/span> Incident Lifecycle on Your Status Page<\/a><\/li><li><a href=\"#Planned_Maintenance_and_Soft_Downtime\"><span class=\"toc_number toc_depth_2\">8.2<\/span> Planned Maintenance and \u201cSoft Downtime\u201d<\/a><\/li><\/ul><\/li><li><a href=\"#Other_Tools_to_Combine_with_Uptime_Kuma\"><span class=\"toc_number toc_depth_1\">9<\/span> Other Tools to Combine with Uptime Kuma<\/a><\/li><li><a href=\"#Best_Practices_and_Common_Pitfalls\"><span class=\"toc_number toc_depth_1\">10<\/span> Best Practices and Common Pitfalls<\/a><ul><li><a href=\"#Best_Practices\"><span class=\"toc_number toc_depth_2\">10.1<\/span> Best Practices<\/a><\/li><li><a href=\"#Common_Pitfalls\"><span class=\"toc_number toc_depth_2\">10.2<\/span> Common Pitfalls<\/a><\/li><\/ul><\/li><li><a href=\"#Summary_Turn_Uptime_Monitoring_into_a_Transparent_Service_Experience\"><span class=\"toc_number toc_depth_1\">11<\/span> Summary: Turn Uptime Monitoring into a Transparent Service Experience<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_a_Dedicated_Status_Page_Matters_More_Than_an_Error_Message\">Why a Dedicated Status Page Matters More Than an Error Message<\/span><\/h2>\n<p>Many site owners assume a simple error message or maintenance page is enough. In reality, customers and internal teams need three things during any incident: visibility, consistency and history.<\/p>\n<ul>\n<li><strong>Visibility:<\/strong> A public URL where anyone can instantly see if the service is healthy or degraded.<\/li>\n<li><strong>Consistency:<\/strong> One authoritative place that matches what your monitoring tools are seeing.<\/li>\n<li><strong>History:<\/strong> A timeline of past incidents and uptime that builds long-term trust.<\/li>\n<\/ul>\n<p>If you already care about uptime and SLAs, you have probably read explanations of concepts like error budgets and \u201cthree nines\u201d. Our own article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/uptime-nedir-web-siteleri-icin-surekli-erisilebilirlik-saglamanin-yollari\/\">what uptime means and how to ensure continuous availability<\/a> explains these fundamentals from a hosting perspective. A status page is the user-facing extension of that work: instead of only your technical team seeing graphs and alerts, you publish an understandable view for customers, colleagues, support and management.<\/p>\n<p>Self-hosting a status page with tools like Uptime Kuma lets you keep costs predictable, customize the design, integrate tightly with your own infrastructure and avoid being dependent on a single third\u2011party SaaS dashboard.<\/p>\n<h2><span id=\"The_Building_Blocks_of_an_Uptime_Status_Stack\">The Building Blocks of an Uptime &amp; Status Stack<\/span><\/h2>\n<p>Before choosing tools, it helps to map the components of an observability and communication stack. At a minimum you need:<\/p>\n<ul>\n<li><strong>Probes \/ Monitors:<\/strong> Periodic checks that test endpoints (HTTP, HTTPS, TCP ports, ICMP ping, DNS, etc.).<\/li>\n<li><strong>Alerting:<\/strong> Rules that turn monitor failures into notifications via email, chat, SMS or webhooks.<\/li>\n<li><strong>Status page:<\/strong> A human-friendly dashboard that shows component health, incidents and scheduled maintenance.<\/li>\n<li><strong>Incident workflow:<\/strong> A simple process for declaring incidents, posting updates and closing them after resolution.<\/li>\n<li><strong>Post\u2011incident history:<\/strong> A log of past events, ideally with metrics like uptime percentage per component.<\/li>\n<\/ul>\n<p>In a small business, you might start with basic HTTP checks and email alerts. We covered this in detail in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/web-sitesi-uptime-izleme-ve-alarm-kurma-rehberi\/\">website uptime monitoring and alerting guide for small businesses<\/a>. Uptime Kuma builds on this foundation: it provides both monitors and a status page in one tool, with a simple UI and strong notification support.<\/p>\n<h2><span id=\"What_Is_Uptime_Kuma_and_Why_Do_We_Like_It\">What Is Uptime Kuma and Why Do We Like It?<\/span><\/h2>\n<p><strong>Uptime Kuma<\/strong> is an open-source uptime monitoring tool and status page generator that you host on your own server. Think of it as a friendly, self-hosted alternative to commercial monitoring dashboards. It offers:<\/p>\n<ul>\n<li><strong>Multiple monitor types:<\/strong> HTTP(S), TCP, ping, DNS, push-based heartbeats, MQTT and more.<\/li>\n<li><strong>Integrated status pages:<\/strong> Public or private pages that show component health, uptime percentages and incident notes.<\/li>\n<li><strong>Flexible notifications:<\/strong> Email, Telegram, Slack-compatible webhooks, Discord, SMS gateways and custom webhooks.<\/li>\n<li><strong>Multi-language interface:<\/strong> Useful for global teams or multilingual businesses.<\/li>\n<li><strong>Self-hosted control:<\/strong> You decide where data lives, how it is backed up and how it is secured.<\/li>\n<li><strong>Container-friendly deployment:<\/strong> Official Docker images make installation predictable.<\/li>\n<\/ul>\n<p>For many dchost.com customers, Uptime Kuma hits a sweet spot: powerful enough for agencies and SaaS projects, but simple enough for a single admin to manage alongside existing hosting services.<\/p>\n<p>If you want to go even deeper on metrics, log analysis and alerting, you can combine Uptime Kuma with Prometheus and Grafana. We\u2019ve written a practical tutorial on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-izleme-ve-alarm-kurulumu-prometheus-grafana-ve-uptime-kuma-ile-baslangic\/\">VPS monitoring and alerts with Prometheus, Grafana and Uptime Kuma<\/a>, which fits perfectly with the status page approach we\u2019ll describe here.<\/p>\n<h2><span id=\"Choosing_Where_to_Host_Your_Uptime_Kuma_Instance\">Choosing Where to Host Your Uptime Kuma Instance<\/span><\/h2>\n<p>Your status page should ideally stay available even when your main production environment has issues. That means placing Uptime Kuma on infrastructure that is:<\/p>\n<ul>\n<li><strong>Stable:<\/strong> Good network connectivity, reliable power and professional data center operations.<\/li>\n<li><strong>Isolated enough:<\/strong> Not sharing every single failure point with the site it monitors.<\/li>\n<li><strong>Easy to secure and back up:<\/strong> Hardening, firewalling and snapshot\/backups should be straightforward.<\/li>\n<\/ul>\n<p>Common patterns we see with our customers:<\/p>\n<ul>\n<li><strong>Small projects:<\/strong> Uptime Kuma hosted on the same VPS as the main site, but with separate containers and backups. Simple and cost\u2011effective.<\/li>\n<li><strong>Growing businesses:<\/strong> Uptime Kuma on a small dedicated VPS at dchost.com, monitoring multiple production servers in different locations.<\/li>\n<li><strong>Larger setups \/ agencies:<\/strong> A dedicated monitoring node (VPS or bare metal) in a separate region or data center, sometimes combined with VPN\/mesh networks for internal checks.<\/li>\n<\/ul>\n<p>Wherever you host it, treat your monitoring server like any other internet-facing system: configure a firewall, close unnecessary ports, enforce TLS and keep software up to date. Our <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-guvenlik-sertlestirme-kontrol-listesi-sshd_config-fail2ban-ve-root-erisimini-kapatmak\/\">VPS security hardening checklist<\/a> and our calmer, step-by-step guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-sunucu-guvenligi-nasil-saglanir-kapiyi-acik-birakmadan-yasamanin-sirri\/\">how to secure a VPS server<\/a> both give you concrete sshd, firewall and update practices that apply perfectly to an Uptime Kuma node.<\/p>\n<h3><span id=\"Basic_Sizing_Guidelines\">Basic Sizing Guidelines<\/span><\/h3>\n<p>Uptime Kuma itself is lightweight. A small VPS (for example, 1 vCPU, 1\u20132 GB RAM and a few GB of disk) can handle dozens to hundreds of monitors without trouble, as long as other workloads are modest. If you plan to monitor many high-traffic services, retain long histories or run Prometheus\/Grafana on the same host, increase CPU, RAM and disk accordingly.<\/p>\n<p>If you\u2019re unsure how to size things, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/yeni-web-sitesi-icin-cpu-ram-ve-trafik-nasil-hesaplanir\/\">calculating CPU, RAM and bandwidth for new websites<\/a> is a good starting point. The same thinking applies to your monitoring stack: estimate how frequently you\u2019ll probe, how many targets you\u2019ll watch and how long you\u2019ll keep data.<\/p>\n<h2><span id=\"Installing_Uptime_Kuma_on_a_VPS_or_Dedicated_Server\">Installing Uptime Kuma on a VPS or Dedicated Server<\/span><\/h2>\n<p>Let\u2019s walk through a practical installation on a Linux VPS. We\u2019ll outline two common approaches:<\/p>\n<ol>\n<li>Running Uptime Kuma via Docker (recommended for most people).<\/li>\n<li>Running it with Node.js directly on the host.<\/li>\n<\/ol>\n<p>These steps assume you have:<\/p>\n<ul>\n<li>Root or sudo access to your server.<\/li>\n<li>A basic firewall (like ufw or firewalld) configured.<\/li>\n<li>A domain or subdomain ready to point to this server for the status page.<\/li>\n<\/ul>\n<h3><span id=\"Option_1_Install_Uptime_Kuma_with_Docker\">Option 1: Install Uptime Kuma with Docker<\/span><\/h3>\n<p>Docker keeps Uptime Kuma and its dependencies separated from your base system, making upgrades and backups easier.<\/p>\n<h4><span id=\"1_Install_Docker\">1. Install Docker<\/span><\/h4>\n<p>On Ubuntu, a typical installation looks like this:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo apt update\nsudo apt install -y ca-certificates curl gnupg lsb-release\n\nsudo mkdir -p \/etc\/apt\/keyrings\ncurl -fsSL https:\/\/download.docker.com\/linux\/ubuntu\/gpg | sudo gpg --dearmor -o \/etc\/apt\/keyrings\/docker.gpg\necho \n  &quot;deb [arch=$(dpkg --print-architecture) signed-by=\/etc\/apt\/keyrings\/docker.gpg] \n  https:\/\/download.docker.com\/linux\/ubuntu \n  $(lsb_release -cs) stable&quot; | sudo tee \/etc\/apt\/sources.list.d\/docker.list &gt; \/dev\/null\n\nsudo apt update\nsudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin\n<\/code><\/pre>\n<p>Enable and start Docker:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo systemctl enable docker --now\n<\/code><\/pre>\n<h4><span id=\"2_Create_Directories_for_Uptime_Kuma\">2. Create Directories for Uptime Kuma<\/span><\/h4>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">sudo mkdir -p \/opt\/uptime-kuma\nsudo mkdir -p \/opt\/uptime-kuma\/data\nsudo chown -R $(whoami):$(whoami) \/opt\/uptime-kuma\n<\/code><\/pre>\n<h4><span id=\"3_Create_a_docker-composeyml\">3. Create a docker-compose.yml<\/span><\/h4>\n<p>In <code>\/opt\/uptime-kuma\/docker-compose.yml<\/code>:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">version: '3.8'\nservices:\n  uptime-kuma:\n    image: louislam\/uptime-kuma:latest\n    container_name: uptime-kuma\n    restart: always\n    volumes:\n      - .\/data:\/app\/data\n    ports:\n      - &quot;3001:3001&quot;  # Internal port\n<\/code><\/pre>\n<h4><span id=\"4_Start_Uptime_Kuma\">4. Start Uptime Kuma<\/span><\/h4>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">cd \/opt\/uptime-kuma\nsudo docker compose up -d\n<\/code><\/pre>\n<p>Now Uptime Kuma listens on port 3001. You can visit <code>http:\/\/&lt;server-ip&gt;:3001<\/code> to complete initial setup. Later, you will put a reverse proxy with HTTPS in front and bind it to a nice domain like <code>status.example.com<\/code>.<\/p>\n<h3><span id=\"Option_2_Install_Uptime_Kuma_Without_Docker_Nodejs\">Option 2: Install Uptime Kuma Without Docker (Node.js)<\/span><\/h3>\n<p>If you prefer not to use containers, you can run Uptime Kuma directly with Node.js. The official documentation provides up-to-date commands, but the rough outline is:<\/p>\n<ol>\n<li>Install Node.js LTS from a trusted repository.<\/li>\n<li>Clone the Uptime Kuma repository.<\/li>\n<li>Install dependencies and build the app.<\/li>\n<li>Run it under a process manager (PM2 or systemd service).<\/li>\n<\/ol>\n<p>For example, after installing Node.js and git:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">cd \/opt\nsudo git clone https:\/\/github.com\/louislam\/uptime-kuma.git\nsudo chown -R $(whoami):$(whoami) uptime-kuma\ncd uptime-kuma\nnpm run setup\n<\/code><\/pre>\n<p>Then you can create a systemd service to keep Uptime Kuma running at boot. The Docker method is usually simpler to keep consistent across environments, especially if you are already using containers for other services.<\/p>\n<h2><span id=\"Putting_Uptime_Kuma_Behind_HTTPS_with_a_Reverse_Proxy\">Putting Uptime Kuma Behind HTTPS with a Reverse Proxy<\/span><\/h2>\n<p>Running a status page on plain HTTP and a raw port is not ideal. Instead, we recommend:<\/p>\n<ul>\n<li>Pointing a domain or subdomain (such as <code>status.example.com<\/code>) to the monitoring server.<\/li>\n<li>Using Nginx, Caddy or another web server as a reverse proxy in front of Uptime Kuma.<\/li>\n<li>Issuing a free TLS certificate via Let\u2019s Encrypt and automating renewals.<\/li>\n<\/ul>\n<p>We have covered full HTTP to HTTPS migrations, including HSTS and canonical settings, in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/httpden-httpsye-gecis-rehberi-seo-kayipsiz-ssl-migrasyonu-hsts-ve-canonical-ayarlari\/\">safe SSL migrations without SEO loss<\/a>. The same principles apply to your status domain: enforce HTTPS, set appropriate redirects and keep certificates renewed automatically.<\/p>\n<h3><span id=\"Example_Nginx_Reverse_Proxy\">Example Nginx Reverse Proxy<\/span><\/h3>\n<p>A simple Nginx configuration (assuming Uptime Kuma listens on <code>localhost:3001<\/code>):<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">server {\n    listen 80;\n    server_name status.example.com;\n\n    location \/ {\n        proxy_pass http:\/\/127.0.0.1:3001\/;\n        proxy_set_header Host $host;\n        proxy_set_header X-Real-IP $remote_addr;\n        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n        proxy_set_header X-Forwarded-Proto $scheme;\n    }\n}\n<\/code><\/pre>\n<p>After verifying that HTTP works, use certbot or your preferred ACME client to add HTTPS and redirects. If you are new to Let\u2019s Encrypt automation, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/lets-encrypt-ile-ucretsiz-ssl-sertifikasi-kurulumu-cpanel-ve-directadminde-otomatik-yenileme-rehberi\/\">free SSL certificates with Let\u2019s Encrypt and automatic renewal<\/a> is a great reference.<\/p>\n<h2><span id=\"Configuring_Monitors_and_Status_Pages_in_Uptime_Kuma\">Configuring Monitors and Status Pages in Uptime Kuma<\/span><\/h2>\n<p>With the base installation ready and HTTPS configured, you can start adding monitors and designing your public status page.<\/p>\n<h3><span id=\"Step_1_Create_Your_First_Monitors\">Step 1: Create Your First Monitors<\/span><\/h3>\n<ol>\n<li>Log into Uptime Kuma as admin.<\/li>\n<li>Click \u201cAdd New Monitor\u201d.<\/li>\n<li>Choose a monitor type, such as HTTP(s) or ping.<\/li>\n<li>Enter the URL or host, friendly name and optional tags or groups.<\/li>\n<li>Set the interval (for example, every 30 seconds or 1 minute).<\/li>\n<li>Save and watch Uptime Kuma start collecting data.<\/li>\n<\/ol>\n<p>Some useful monitor types in practice:<\/p>\n<ul>\n<li><strong>HTTP(s):<\/strong> For websites, APIs and admin panels.<\/li>\n<li><strong>Ping:<\/strong> For servers, routers and network devices.<\/li>\n<li><strong>TCP port:<\/strong> For services such as SSH, SMTP, database ports or custom daemons.<\/li>\n<li><strong>DNS:<\/strong> For verifying that critical domains resolve correctly.<\/li>\n<li><strong>Heartbeat (push):<\/strong> For cron jobs or background workers that call back to Uptime Kuma after successful runs.<\/li>\n<\/ul>\n<h3><span id=\"Step_2_Set_Up_Notifications\">Step 2: Set Up Notifications<\/span><\/h3>\n<p>Next, configure how you want to be alerted.<\/p>\n<ol>\n<li>Open the \u201cNotification\u201d section in Uptime Kuma.<\/li>\n<li>Create one or more notification channels (email, chat, SMS gateway, etc.).<\/li>\n<li>Attach these channels to your monitors or groups.<\/li>\n<li>Fine-tune options like alert thresholds, recovery notifications and silence periods.<\/li>\n<\/ol>\n<p>For critical production systems, you may want a tiered alert strategy: first send emails to the operations team, then escalate to a messaging channel if the incident lasts more than a few minutes.<\/p>\n<h3><span id=\"Step_3_Build_a_Public_Status_Page\">Step 3: Build a Public Status Page<\/span><\/h3>\n<p>Uptime Kuma lets you create one or more status pages and decide which monitors appear on each. To create your main public status page:<\/p>\n<ol>\n<li>Go to the \u201cStatus Pages\u201d section.<\/li>\n<li>Click \u201cNew Status Page\u201d and choose a name and slug (for example, <code>\/status<\/code>).<\/li>\n<li>Select which monitors to show, group them into categories (e.g., \u201cWebsites\u201d, \u201cAPIs\u201d, \u201cBackoffice\u201d).<\/li>\n<li>Customize colors, logos and texts to match your brand.<\/li>\n<li>Choose whether the page is public or password-protected.<\/li>\n<\/ol>\n<p>Many organizations use multiple pages: a public customer-facing status page and a more detailed internal status dashboard that exposes extra checks (for example, staging environments, in-office infrastructure or third\u2011party dependencies).<\/p>\n<h2><span id=\"Designing_Clear_Incident_and_Maintenance_Communication\">Designing Clear Incident and Maintenance Communication<\/span><\/h2>\n<p>A technically perfect monitoring setup is less useful if your communication during incidents is vague or inconsistent. You want your status page to answer three questions for users:<\/p>\n<ul>\n<li>\u201cIs there a problem right now?\u201d<\/li>\n<li>\u201cWhat\u2019s affected and what are you doing about it?\u201d<\/li>\n<li>\u201cWhen can I expect it to be resolved?\u201d<\/li>\n<\/ul>\n<h3><span id=\"Incident_Lifecycle_on_Your_Status_Page\">Incident Lifecycle on Your Status Page<\/span><\/h3>\n<p>A simple, repeatable incident process might look like this:<\/p>\n<ol>\n<li><strong>Detection:<\/strong> Uptime Kuma marks a monitor as down and sends alerts.<\/li>\n<li><strong>Verification:<\/strong> An engineer confirms that the incident is real (not a false positive) and its scope.<\/li>\n<li><strong>Declaration:<\/strong> You create an incident entry on the status page, set the impacted components and add an initial message.<\/li>\n<li><strong>Updates:<\/strong> As you work, you post concise updates (e.g. root cause identified, workaround applied, monitoring recovery).<\/li>\n<li><strong>Resolution:<\/strong> Once systems are stable, you mark the incident as resolved.<\/li>\n<li><strong>Postmortem (optional but recommended):<\/strong> For major incidents, you later add a root cause and prevention summary.<\/li>\n<\/ol>\n<p>You can use incident templates or predefined phrases to keep messages consistent. Avoid overly technical jargon; reserve deep technical analysis for internal documents.<\/p>\n<h3><span id=\"Planned_Maintenance_and_Soft_Downtime\">Planned Maintenance and \u201cSoft Downtime\u201d<\/span><\/h3>\n<p>Planned maintenance is your chance to demonstrate professionalism rather than surprise users. Uptime Kuma lets you mark periods as scheduled maintenance or temporarily disable alerts. Combine that with a status page announcement so customers know what to expect.<\/p>\n<p>We covered this in depth in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/bakim-modu-ve-planli-kesinti-yonetimi-seo-kaybi-yasamadan-maintenance-page-yayinlama-rehberi\/\">maintenance windows and downtime pages<\/a>. The key ideas you can reuse for your status page:<\/p>\n<ul>\n<li>Announce maintenance early and clearly, including local times for major customer regions.<\/li>\n<li>Set expectations on impact (full downtime, read\u2011only mode, performance degradation).<\/li>\n<li>Update the status page during the window if anything changes.<\/li>\n<li>Close the maintenance event with a short summary of what was done.<\/li>\n<\/ul>\n<h2><span id=\"Other_Tools_to_Combine_with_Uptime_Kuma\">Other Tools to Combine with Uptime Kuma<\/span><\/h2>\n<p>Uptime Kuma is excellent for availability checks and human\u2011friendly status pages. For a more complete observability stack you can pair it with other open-source components:<\/p>\n<ul>\n<li><strong>Prometheus:<\/strong> Time\u2011series metrics for CPU, RAM, disk, HTTP latency and custom business metrics.<\/li>\n<li><strong>Grafana:<\/strong> Dashboards and visualization on top of Prometheus and other data sources.<\/li>\n<li><strong>Centralized logging (Loki, ELK):<\/strong> To correlate errors and performance changes with uptime events.<\/li>\n<li><strong>Error tracking (Sentry, etc.):<\/strong> For application-level exceptions and frontend issues.<\/li>\n<\/ul>\n<p>Uptime Kuma can also send webhooks, so you can trigger external automation when checks fail (for example, toggling a feature flag, triggering a deploy rollback or opening an issue in your ticketing system).<\/p>\n<p>For agencies and teams managing many clients, it\u2019s common to run a monitoring stack in its own VPS or dedicated server, then configure each client project to be watched from there. Combined with our guidance on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ajanslar-icin-musteri-sitelerini-izleme-mimarisi-uptime-ssl-ve-domain-alarm-sistemi\/\">monitoring client websites at scale (uptime, SSL and domain renewal alerts)<\/a>, Uptime Kuma becomes the public face of a robust internal monitoring and alerting pipeline.<\/p>\n<h2><span id=\"Best_Practices_and_Common_Pitfalls\">Best Practices and Common Pitfalls<\/span><\/h2>\n<h3><span id=\"Best_Practices\">Best Practices<\/span><\/h3>\n<ul>\n<li><strong>Monitor what matters, not everything:<\/strong> Focus on user-facing endpoints and critical dependencies. Too many noisy checks will reduce signal quality.<\/li>\n<li><strong>Use multiple check types:<\/strong> Combine HTTP checks with ping\/TCP for a clearer picture of whether a host is up but the application is misbehaving.<\/li>\n<li><strong>Test alert channels:<\/strong> Do a controlled test outage and make sure alerts actually reach inboxes, chat channels and phones.<\/li>\n<li><strong>Document your incident playbook:<\/strong> Write down who declares incidents, who updates the status page and who has final say on resolution.<\/li>\n<li><strong>Secure your monitoring server:<\/strong> Restrict panel access, enforce strong passwords and 2FA where possible, and regularly update packages.<\/li>\n<li><strong>Back up Uptime Kuma data:<\/strong> The <code>data<\/code> directory (or container volume) contains your configuration and history; include it in your regular backup job.<\/li>\n<\/ul>\n<h3><span id=\"Common_Pitfalls\">Common Pitfalls<\/span><\/h3>\n<ul>\n<li><strong>Hosting status page and main site on the same fragile server:<\/strong> If that single server fails, both your service and the status page vanish. Consider at least a small separate VPS.<\/li>\n<li><strong>Too aggressive intervals:<\/strong> Extremely frequent checks (e.g. every second) may cause false positives and unnecessary load. Start with 30\u201360 seconds and adjust.<\/li>\n<li><strong>Ignoring SSL\/TLS on the status page:<\/strong> Users expect sensitive information (like incident descriptions or case URLs) to be served over HTTPS.<\/li>\n<li><strong>Overly technical messaging:<\/strong> \u201cTCP timeout from backend 10.12.3.5:9000\u201d means little to non\u2011technical stakeholders. Translate it into impact: \u201cCheckout requests are failing for some users; we\u2019re rolling back a configuration change.\u201d<\/li>\n<li><strong>No redundancy for notifications:<\/strong> Relying on a single email system or chat integration can delay alerts. Add a backup notification path.<\/li>\n<\/ul>\n<h2><span id=\"Summary_Turn_Uptime_Monitoring_into_a_Transparent_Service_Experience\">Summary: Turn Uptime Monitoring into a Transparent Service Experience<\/span><\/h2>\n<p>A status page is more than a pretty dashboard; it\u2019s part of your brand promise. When you pair reliable probing with honest, timely communication, you show customers that you take reliability seriously even when things are not perfect. With Uptime Kuma you can self\u2011host that capability on your own VPS, dedicated server or colocated hardware at dchost.com, keep full control over your data, integrate with existing monitoring tools and customize the look and feel.<\/p>\n<p>The journey typically looks like this: start by defining what you need to monitor, deploy Uptime Kuma on a secure server, place it behind HTTPS with a dedicated status domain, configure a handful of monitors and notifications, then iterate on your incident and maintenance communication style. As your infrastructure grows, you can connect Uptime Kuma to Prometheus, Grafana, centralized logs and more advanced failover or scaling architectures.<\/p>\n<p>If you want help choosing the right hosting environment for your monitoring stack or sizing a VPS for your applications and status page together, our team at dchost.com is ready to assist. Explore our VPS, dedicated and colocation options, and combine them with the best practices we\u2019ve shared here and in our other guides to build a calm, predictable uptime and communication platform your users can rely on.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Monitoring whether your website, API or store is really online is only half of the story. When something goes wrong, customers want a clear, always-available source of truth: a status page that shows current uptime, incident details and maintenance plans. In many teams this starts as a simple question in a planning or architecture meeting: [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4702,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4701","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4701","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4701"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4701\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4702"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4701"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4701"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4701"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}