[{"data":1,"prerenderedAt":5413},["ShallowReactive",2],{"alternatives-guides-en":3},[4,854,1673,2246,2842,3300,3697,4482,5015],{"id":5,"title":6,"body":7,"category":834,"description":835,"extension":836,"faq":837,"meta":838,"navigation":334,"path":839,"peerSlug":840,"publishedAt":841,"readingTime":842,"relatedComparisons":843,"relatedGuides":847,"seo":851,"stem":852,"updatedAt":837,"__hash__":853},"guides\u002Fguides\u002Fen\u002Fcronjob-monitoring.md","Cron Job Monitoring: Heartbeat Monitoring in Practice",{"type":8,"value":9,"toc":815},"minimark",[10,15,30,38,51,57,61,64,69,72,98,101,171,178,182,189,196,200,203,247,254,258,261,295,299,303,306,356,359,363,366,391,417,421,424,505,509,524,545,551,555,581,607,611,614,708,724,728,743,766,769,773,776,805,811],[11,12,14],"h2",{"id":13},"why-cron-jobs-fail-silently","Why cron jobs fail silently",[16,17,18,19,24,25,29],"p",{},"A crashed web server gets noticed immediately: visitors see error pages, ",[20,21,23],"a",{"href":22},"\u002Fen\u002Fguides\u002Fuptime-monitoring","uptime monitoring"," fires an alert, support tickets roll in. A cron job that stopped running gets noticed by ",[26,27,28],"strong",{},"nobody"," — until it is too late.",[16,31,32,33,37],{},"The nightly backup, the invoice run on the first of the month, the queue worker, the import from your ERP system: none of these jobs have a port, a URL, or users who complain. When they fail, no error appears — simply ",[34,35,36],"em",{},"nothing"," happens. And that is exactly what makes them dangerous:",[39,40,41,45,48],"ul",{},[42,43,44],"li",{},"A backup script that has not run for three months gets noticed the moment you need the backup.",[42,46,47],{},"A stuck invoice run only surfaces when customers call asking where their invoice went.",[42,49,50],{},"A stopped queue worker silently piles up thousands of jobs until memory runs out.",[16,52,53,54],{},"Classic monitoring does not help here. An HTTP check can verify that your website responds — but no monitoring system in the world can see from the outside whether a script on your server ran last night. The solution is to invert the principle: ",[26,55,56],{},"the monitoring does not ask the job — the job reports to the monitoring.",[11,58,60],{"id":59},"how-heartbeat-monitoring-works","How heartbeat monitoring works",[16,62,63],{},"Heartbeat monitoring (also called a dead man's switch, after the safety device in a train cab) is built on a missing signal: the job sends a short sign of life after every successful run. If the sign of life stays out, an alert fires.",[65,66,68],"h3",{"id":67},"ping-url-and-expectation-window","Ping URL and expectation window",[16,70,71],{},"The flow takes three steps to explain:",[73,74,75,86,92],"ol",{},[42,76,77,80,81,85],{},[26,78,79],{},"Ping URL:"," The monitoring provides a unique URL for each job. The job calls it at the end via HTTP — a single ",[82,83,84],"code",{},"curl"," is enough.",[42,87,88,91],{},[26,89,90],{},"Expectation window:"," From the job's schedule (cron expression or \"every 15 minutes\"), the monitoring calculates when the next ping is due.",[42,93,94,97],{},[26,95,96],{},"Alert:"," If the ping does not arrive within the window, the job counts as failed — and alerting kicks in.",[16,99,100],{},"In the crontab, it looks like this:",[102,103,108],"pre",{"className":104,"code":105,"language":106,"meta":107,"style":107},"language-bash shiki shiki-themes github-light github-dark","# Backup at 2:00 AM — ping ONLY on success\n0 2 * * * \u002Fusr\u002Flocal\u002Fbin\u002Fbackup.sh && curl -fsS -m 10 --retry 5 -o \u002Fdev\u002Fnull https:\u002F\u002Fmonitoring.example.com\u002Fping\u002Fa1b2c3\n","bash","",[82,109,110,119],{"__ignoreMap":107},[111,112,115],"span",{"class":113,"line":114},"line",1,[111,116,118],{"class":117},"sJ8bj","# Backup at 2:00 AM — ping ONLY on success\n",[111,120,122,126,130,133,135,137,141,145,147,150,153,156,159,162,165,168],{"class":113,"line":121},2,[111,123,125],{"class":124},"sScJk","0",[111,127,129],{"class":128},"sj4cs"," 2",[111,131,132],{"class":128}," *",[111,134,132],{"class":128},[111,136,132],{"class":128},[111,138,140],{"class":139},"sZZnC"," \u002Fusr\u002Flocal\u002Fbin\u002Fbackup.sh",[111,142,144],{"class":143},"sVt8B"," && ",[111,146,84],{"class":124},[111,148,149],{"class":128}," -fsS",[111,151,152],{"class":128}," -m",[111,154,155],{"class":128}," 10",[111,157,158],{"class":128}," --retry",[111,160,161],{"class":128}," 5",[111,163,164],{"class":128}," -o",[111,166,167],{"class":139}," \u002Fdev\u002Fnull",[111,169,170],{"class":139}," https:\u002F\u002Fmonitoring.example.com\u002Fping\u002Fa1b2c3\n",[16,172,173,174,177],{},"The ",[82,175,176],{},"&&"," here is not a detail — it is the core of the whole setup. More on that in a moment.",[65,179,181],{"id":180},"sizing-the-grace-period","Sizing the grace period",[16,183,184,185,188],{},"No job runs for exactly the same duration every time. To keep natural variance from triggering false alarms, there is the ",[26,186,187],{},"grace period",": a buffer after the expected time before the alert fires.",[16,190,191,192,195],{},"The rule of thumb: base it on the ",[34,193,194],{},"maximum"," realistic runtime, not the average. If your backup normally takes 5 to 15 minutes, a grace period of 30 minutes is reasonable. Set it too tight and it produces false alarms and alert fatigue — set it too generously and it gives away reaction time. For jobs with highly variable runtimes, start pings plus a runtime limit beat an overstretched grace period.",[65,197,199],{"id":198},"start-and-end-pings","Start and end pings",[16,201,202],{},"Advanced setups send two signals: one when the job starts, one at the end. That makes three states distinguishable that a single ping cannot separate:",[204,205,206,219],"table",{},[207,208,209],"thead",{},[210,211,212,216],"tr",{},[213,214,215],"th",{},"Signal pattern",[213,217,218],{},"Meaning",[220,221,222,231,239],"tbody",{},[210,223,224,228],{},[225,226,227],"td",{},"No start ping",[225,229,230],{},"Job never started (cron daemon, crontab, server)",[210,232,233,236],{},[225,234,235],{},"Start ping without end ping",[225,237,238],{},"Job started but crashed or hangs",[210,240,241,244],{},[225,242,243],{},"Start + end, but excessive duration",[225,245,246],{},"Job runs, but something slows it down",[16,248,249,250,253],{},"As a bonus, the ",[26,251,252],{},"runtime becomes measurable"," — and a job that gets gradually slower stands out before it grows into the time window of its next run. Some services additionally accept an explicit fail ping with an exit code: the job then reports its failure immediately instead of surfacing only after the expectation window expires.",[11,255,257],{"id":256},"the-four-failure-modes-of-a-cron-job","The four failure modes of a cron job",[16,259,260],{},"Cron jobs fail in four fundamentally different ways — and each needs a different detection mechanism:",[73,262,263,277,283,289],{},[42,264,265,268,269,272,273,276],{},[26,266,267],{},"The job does not run at all."," Server down, cron daemon stopped, crontab overwritten during a deployment, typo in the schedule. The treacherous part: ",[34,270,271],{},"no"," log entry is created, because nothing runs. This failure class is detectable ",[26,274,275],{},"only"," via a dead man's switch.",[42,278,279,282],{},[26,280,281],{},"The job hangs or runs too long."," A hanging database query, a blocked mount, a lock that was never released. Detection: start ping without end ping, or a breached runtime limit.",[42,284,285,288],{},[26,286,287],{},"The job runs too often."," A duplicated crontab entry, the same job on two servers, overlap with the previous run. Detection: pings outside the expected schedule.",[42,290,291,294],{},[26,292,293],{},"The job completes — but the result is wrong."," The most dangerous case: exit code 0, ping sent, but the backup is a 0-byte file. No external monitoring helps here — the script itself must validate its result (file size, row count, checksum) and exit with an error when in doubt.",[11,296,298],{"id":297},"best-practices-for-reliable-pings","Best practices for reliable pings",[65,300,302],{"id":301},"instead-of-semicolon","&& instead of semicolon",[16,304,305],{},"The single most important tip in this guide. These two lines look almost identical and separate a working monitoring setup from a useless one:",[102,307,309],{"className":104,"code":308,"language":106,"meta":107,"style":107},"# CORRECT: ping only if backup.sh exits with 0\nbackup.sh && curl -fsS https:\u002F\u002Fmonitoring.example.com\u002Fping\u002Fa1b2c3\n\n# WRONG: ping is ALWAYS sent — even if backup.sh fails\nbackup.sh ; curl -fsS https:\u002F\u002Fmonitoring.example.com\u002Fping\u002Fa1b2c3\n",[82,310,311,316,329,336,342],{"__ignoreMap":107},[111,312,313],{"class":113,"line":114},[111,314,315],{"class":117},"# CORRECT: ping only if backup.sh exits with 0\n",[111,317,318,321,323,325,327],{"class":113,"line":121},[111,319,320],{"class":124},"backup.sh",[111,322,144],{"class":143},[111,324,84],{"class":124},[111,326,149],{"class":128},[111,328,170],{"class":139},[111,330,332],{"class":113,"line":331},3,[111,333,335],{"emptyLinePlaceholder":334},true,"\n",[111,337,339],{"class":113,"line":338},4,[111,340,341],{"class":117},"# WRONG: ping is ALWAYS sent — even if backup.sh fails\n",[111,343,345,347,350,352,354],{"class":113,"line":344},5,[111,346,320],{"class":124},[111,348,349],{"class":143}," ; ",[111,351,84],{"class":124},[111,353,149],{"class":128},[111,355,170],{"class":139},[16,357,358],{},"With the semicolon, the job reports success even when the backup failed. The monitoring shows permanent green — which is worse than no monitoring at all, because it creates false confidence.",[65,360,362],{"id":361},"calling-curl-correctly","Calling curl correctly",[16,364,365],{},"The ping itself must neither stall nor break the job. The proven flag combination:",[102,367,369],{"className":104,"code":368,"language":106,"meta":107,"style":107},"curl -fsS -m 10 --retry 5 -o \u002Fdev\u002Fnull https:\u002F\u002Fmonitoring.example.com\u002Fping\u002Fa1b2c3\n",[82,370,371],{"__ignoreMap":107},[111,372,373,375,377,379,381,383,385,387,389],{"class":113,"line":114},[111,374,84],{"class":124},[111,376,149],{"class":128},[111,378,152],{"class":128},[111,380,155],{"class":128},[111,382,158],{"class":128},[111,384,161],{"class":128},[111,386,164],{"class":128},[111,388,167],{"class":139},[111,390,170],{"class":139},[39,392,393,399,405,411],{},[42,394,395,398],{},[82,396,397],{},"-m 10"," — timeout: the ping never hangs longer than 10 seconds, even if the monitoring is unreachable.",[42,400,401,404],{},[82,402,403],{},"--retry 5"," — transient network errors get absorbed instead of producing a false alarm.",[42,406,407,410],{},[82,408,409],{},"-fsS"," — silent on success, but errors stay visible in the log.",[42,412,413,416],{},[82,414,415],{},"-o \u002Fdev\u002Fnull"," — the response body does not matter, only the delivery.",[65,418,420],{"id":419},"preventing-overlaps-and-hangs","Preventing overlaps and hangs",[16,422,423],{},"Two small standard tools solve two big problem classes:",[102,425,427],{"className":104,"code":426,"language":106,"meta":107,"style":107},"# flock: prevents a new run from starting while the old one is still running\n0 * * * * flock -n \u002Ftmp\u002Fimport.lock \u002Fusr\u002Flocal\u002Fbin\u002Fimport.sh && curl -fsS https:\u002F\u002F…\u002Fping\u002Fimport\n\n# timeout: a job can never hang forever (exit 124 after 25 minutes)\n0 2 * * * timeout 25m \u002Fusr\u002Flocal\u002Fbin\u002Fbackup.sh && curl -fsS https:\u002F\u002F…\u002Fping\u002Fbackup\n",[82,428,429,434,467,471,476],{"__ignoreMap":107},[111,430,431],{"class":113,"line":114},[111,432,433],{"class":117},"# flock: prevents a new run from starting while the old one is still running\n",[111,435,436,438,440,442,444,446,449,452,455,458,460,462,464],{"class":113,"line":121},[111,437,125],{"class":124},[111,439,132],{"class":128},[111,441,132],{"class":128},[111,443,132],{"class":128},[111,445,132],{"class":128},[111,447,448],{"class":139}," flock",[111,450,451],{"class":128}," -n",[111,453,454],{"class":139}," \u002Ftmp\u002Fimport.lock",[111,456,457],{"class":139}," \u002Fusr\u002Flocal\u002Fbin\u002Fimport.sh",[111,459,144],{"class":143},[111,461,84],{"class":124},[111,463,149],{"class":128},[111,465,466],{"class":139}," https:\u002F\u002F…\u002Fping\u002Fimport\n",[111,468,469],{"class":113,"line":331},[111,470,335],{"emptyLinePlaceholder":334},[111,472,473],{"class":113,"line":338},[111,474,475],{"class":117},"# timeout: a job can never hang forever (exit 124 after 25 minutes)\n",[111,477,478,480,482,484,486,488,491,494,496,498,500,502],{"class":113,"line":344},[111,479,125],{"class":124},[111,481,129],{"class":128},[111,483,132],{"class":128},[111,485,132],{"class":128},[111,487,132],{"class":128},[111,489,490],{"class":139}," timeout",[111,492,493],{"class":139}," 25m",[111,495,140],{"class":139},[111,497,144],{"class":143},[111,499,84],{"class":124},[111,501,149],{"class":128},[111,503,504],{"class":139}," https:\u002F\u002F…\u002Fping\u002Fbackup\n",[65,506,508],{"id":507},"keeping-exit-codes-honest","Keeping exit codes honest",[16,510,511,512,515,516,519,520,523],{},"Bash scripts like to mask errors — a pipe such as ",[82,513,514],{},"pg_dump | gzip"," returns the exit code of ",[82,517,518],{},"gzip",", even if ",[82,521,522],{},"pg_dump"," failed. Three lines at the top of the script restore order:",[102,525,527],{"className":104,"code":526,"language":106,"meta":107,"style":107},"#!\u002Fusr\u002Fbin\u002Fenv bash\nset -euo pipefail\n",[82,528,529,534],{"__ignoreMap":107},[111,530,531],{"class":113,"line":114},[111,532,533],{"class":117},"#!\u002Fusr\u002Fbin\u002Fenv bash\n",[111,535,536,539,542],{"class":113,"line":121},[111,537,538],{"class":128},"set",[111,540,541],{"class":128}," -euo",[111,543,544],{"class":139}," pipefail\n",[16,546,547,548,550],{},"With this, the script aborts on every error, every unset variable and every pipe failure — and the success ping behind the ",[82,549,176],{}," stays out, exactly as it should.",[11,552,554],{"id":553},"systemd-timers-and-kubernetes-cronjobs","systemd timers and Kubernetes CronJobs",[16,556,557,560,561,564,565,568,569,572,573,576,577,580],{},[26,558,559],{},"systemd timers"," are the successor to classic cron jobs on modern Linux systems and bring more to the table out of the box: logs via ",[82,562,563],{},"journalctl",", ",[82,566,567],{},"Persistent=true"," to catch up on missed runs, and ",[82,570,571],{},"OnFailure="," hooks for local reactions. What they ",[34,574,575],{},"cannot"," do: alert externally. If the whole server goes down, a local hook reports nothing. The external heartbeat remains mandatory here too — cleanly wired up via ",[82,578,579],{},"ExecStartPost=",", which only executes after a successful run.",[16,582,583,586,587,590,591,594,595,598,599,602,603,606],{},[26,584,585],{},"Kubernetes CronJobs"," have failure classes that classic cron does not know: image pull errors, pods stuck in ",[82,588,589],{},"Pending"," forever due to missing resources, missed ",[82,592,593],{},"startingDeadlineSeconds",", or a badly chosen ",[82,596,597],{},"concurrencyPolicy",". ",[82,600,601],{},"kubectl get cronjob"," only shows the last status — Kubernetes provides neither history nor alerting. The simplest robust approach is the same as everywhere: a ",[82,604,605],{},"&& curl …"," ping at the end of the container command, evaluated by an external heartbeat monitoring service.",[11,608,610],{"id":609},"comparing-the-tools","Comparing the tools",[16,612,613],{},"The niche is well populated — an honest look at the free entry points (as of July 2026):",[204,615,616,629],{},[207,617,618],{},[210,619,620,623,626],{},[213,621,622],{},"Tool",[213,624,625],{},"Free",[213,627,628],{},"Paid from",[220,630,631,642,653,664,675,686,697],{},[210,632,633,636,639],{},[225,634,635],{},"LIVCK",[225,637,638],{},"Self-hosted EUR 0 (commercial use allowed) · Cloud Free: 20 services (public beta)",[225,640,641],{},"Self-hosted license from EUR 9.90\u002Fmonth",[210,643,644,647,650],{},[225,645,646],{},"Healthchecks.io",[225,648,649],{},"20 checks, 3 team members",[225,651,652],{},"Business $20\u002Fmonth (100 checks)",[210,654,655,658,661],{},[225,656,657],{},"Cronitor",[225,659,660],{},"5 monitors, 5-min interval",[225,662,663],{},"$2\u002Fmonitor + $5\u002Fuser",[210,665,666,669,672],{},[225,667,668],{},"Dead Man's Snitch",[225,670,671],{},"1 snitch, standard intervals only",[225,673,674],{},"$5\u002Fmonth (3 snitches)",[210,676,677,680,683],{},[225,678,679],{},"Sentry Crons",[225,681,682],{},"1 cron monitor",[225,684,685],{},"$0.78\u002Fmonitor (paid plans only)",[210,687,688,691,694],{},[225,689,690],{},"UptimeRobot",[225,692,693],{},"Heartbeat on free plan, 5-min interval",[225,695,696],{},"Pro for 1-min checks",[210,698,699,702,705],{},[225,700,701],{},"Better Stack",[225,703,704],{},"10 heartbeats, 3-min interval",[225,706,707],{},"+$17\u002Fmonth per additional 10",[16,709,710,711,714,715,718,719,723],{},"Worth noting in the fine print: ",[20,712,646],{"href":713},"\u002Fen\u002Fhealthchecks-io-alternative"," is open source and self-hostable — the classic choice for the frugal, but a pure cron job tool without uptime monitoring or a statuspage. ",[20,716,657],{"href":717},"\u002Fen\u002Fcronitor-alternative"," is the most mature at pure cron job monitoring, but bills per monitor and per user — growing setups get expensive fast. And ",[20,720,722],{"href":721},"\u002Fen\u002Fuptimerobot-alternative","UptimeRobot's"," free plan only covers non-commercial use.",[11,725,727],{"id":726},"cron-job-monitoring-with-livck","Cron job monitoring with LIVCK",[16,729,730,731,734,735,738,739,742],{},"LIVCK ships heartbeat monitoring as one of seven check types — alongside HTTP(S), TCP, ping, DNS, SSL and Manual\u002FAPI. The schedule accepts simple intervals or ",[26,732,733],{},"real cron expressions with time zones",", and via the ",[82,736,737],{},"\u002Fstart"," and ",[82,740,741],{},"\u002Ffail"," signals plus exit codes, LIVCK tells \"never started\" apart from \"crashed\" — including runtime measurement and a maximum-runtime guard against hanging jobs. If the expected signal stays out, alerting fires via email, SMS, voice call, Slack, Microsoft Teams, Telegram or Discord.",[16,744,745,746,750,751,754,755,761,762,765],{},"The real difference from the specialists lies in the complete package: with LIVCK, a failed heartbeat is not just an internal alert — it can flow directly into the ",[20,747,749],{"href":748},"\u002Fen\u002Fguides\u002Fincident-management","statuspage and incident management",", turning a silent cron job failure into transparent communication in a single tool. For operation, the choice is yours: ",[26,752,753],{},"self-hosted via Docker Compose"," (EUR 0, commercial use allowed — runs on a ",[20,756,760],{"href":757,"rel":758},"https:\u002F\u002Flivck.com\u002Fr\u002Fhetzner",[759],"nofollow","Hetzner server from under EUR 5\u002Fmonth","), a managed service on German servers, or ",[26,763,764],{},"LIVCK Cloud"," with a free plan (20 services) — public beta, access via the waitlist. Since LIVCK is built in Germany and works GDPR by design, your monitoring data stays where it belongs.",[16,767,768],{},"Especially after the Freshping shutdown, the self-hosted approach is more than a matter of taste: no vendor can switch off monitoring that runs on your own server.",[11,770,772],{"id":771},"conclusion","Conclusion",[16,774,775],{},"Cron jobs are the quietest failures in any infrastructure: no port, no error message, no angry user — just a job that at some point simply stops running. Heartbeat monitoring inverts the principle and turns the absence itself into the alert signal.",[16,777,778,779,782,783,785,786,789,790,792,793,796,797,800,801,804],{},"The essence of this guide: send the ping ",[26,780,781],{},"only on success"," (",[82,784,176],{},", never ",[82,787,788],{},";","), harden ",[82,791,84],{}," with timeout and retries, size the grace period on maximum rather than average runtime, prevent overlaps with ",[82,794,795],{},"flock"," and hangs with ",[82,798,799],{},"timeout"," — and keep scripts honest with ",[82,802,803],{},"set -euo pipefail",". If you add start pings, you can tell \"never started\" from \"crashed\" and see runtime trends before they become a problem.",[16,806,807,808,810],{},"And just like with ",[20,809,23],{"href":22},", the same rule applies here: monitoring belongs on independent infrastructure — otherwise it goes down together with the very jobs it is supposed to watch.",[812,813,814],"style",{},"html pre.shiki code .sJ8bj, html code.shiki .sJ8bj{--shiki-default:#6A737D;--shiki-dark:#6A737D}html pre.shiki code .sScJk, html code.shiki .sScJk{--shiki-default:#6F42C1;--shiki-dark:#B392F0}html pre.shiki code .sj4cs, html code.shiki .sj4cs{--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .sZZnC, html code.shiki .sZZnC{--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .sVt8B, html code.shiki .sVt8B{--shiki-default:#24292E;--shiki-dark:#E1E4E8}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":107,"searchDepth":121,"depth":121,"links":816},[817,818,823,824,830,831,832,833],{"id":13,"depth":121,"text":14},{"id":59,"depth":121,"text":60,"children":819},[820,821,822],{"id":67,"depth":331,"text":68},{"id":180,"depth":331,"text":181},{"id":198,"depth":331,"text":199},{"id":256,"depth":121,"text":257},{"id":297,"depth":121,"text":298,"children":825},[826,827,828,829],{"id":301,"depth":331,"text":302},{"id":361,"depth":331,"text":362},{"id":419,"depth":331,"text":420},{"id":507,"depth":331,"text":508},{"id":553,"depth":121,"text":554},{"id":609,"depth":121,"text":610},{"id":726,"depth":121,"text":727},{"id":771,"depth":121,"text":772},"Monitoring","Monitor cron jobs with heartbeat monitoring: how the dead man's switch works, typical failure modes and best practices for cron, systemd and Kubernetes.","md",null,{},"\u002Fguides\u002Fen\u002Fcronjob-monitoring","cronjob-monitoring","2026-07-03",12,[844,845,846],"healthchecks-io","cronitor","uptimerobot",[848,849,850],"uptime-monitoring","incident-management","self-hosted-statuspage",{"title":6,"description":835},"guides\u002Fen\u002Fcronjob-monitoring","_3LMFS6AdFy12rJti48eZy1wrtxC16WL-4FtMceMgLM",{"id":855,"title":856,"body":857,"category":1632,"description":1633,"extension":836,"faq":1634,"meta":1659,"navigation":334,"path":1660,"peerSlug":1661,"publishedAt":1662,"readingTime":1663,"relatedComparisons":1664,"relatedGuides":1668,"seo":1670,"stem":1671,"updatedAt":837,"__hash__":1672},"guides\u002Fguides\u002Fen\u002Fbest-statuspage-tools.md","The Best Statuspage Tools in 2026: A Detailed Comparison",{"type":8,"value":858,"toc":1609},[859,863,871,874,880,884,887,931,934,938,941,1207,1210,1214,1218,1224,1227,1234,1268,1281,1295,1299,1311,1315,1322,1326,1334,1338,1346,1350,1356,1360,1367,1371,1378,1382,1390,1394,1401,1405,1416,1420,1427,1431,1448,1452,1455,1511,1519,1523,1529,1535,1541,1547,1553,1559,1568,1574,1580,1586,1592,1598,1600,1603,1606],[11,860,862],{"id":861},"what-this-comparison-is-about","What This Comparison Is About",[16,864,865,866,870],{},"A statuspage communicates the availability of your services transparently to users, customers, and partners. When something goes down, slows down, or is under maintenance, your users find out on a dedicated, publicly reachable page — instead of through overloaded support inboxes. One thing matters up front: a statuspage does not replace monitoring, it complements it. Monitoring determines whether a system is running; the statuspage handles the external communication about it. If you want to ",[20,867,869],{"href":868},"\u002Fen\u002Fguides\u002Fwhat-is-a-statuspage","understand a statuspage from the ground up",", that guide covers the fundamentals — this article focuses on the market of the best statuspage tools in 2026.",[16,872,873],{},"This statuspage comparison sorts the relevant vendors by feature scope, price, self-hosting option, and data-privacy suitability. The market for status page software is heterogeneous: some tools are pure statuspage software without their own monitoring, others combine monitoring and statuspage, and still others are really incident-management or alerting platforms that ship a statuspage as an add-on. These exact differences determine which tool fits your use case.",[16,875,876,879],{},[26,877,878],{},"Transparency note:"," statuspage.de belongs to LIVCK. We do not hide that — quite the opposite. The evaluation criteria are nonetheless fact-based and applied equally to every tool. Prices and features come from the vendors' publicly communicated plans (as of June 2026). Where LIVCK has strengths, we name them; where other tools are the better choice for a specific purpose, we say so too. A use-case-based decision aid follows further down.",[11,881,883],{"id":882},"evaluation-criteria","Evaluation Criteria",[16,885,886],{},"To keep the comparison transparent, we apply the same criteria to every tool:",[39,888,889,895,901,907,913,919,925],{},[42,890,891,894],{},[26,892,893],{},"Monitoring included?"," Does the tool bring its own uptime monitoring, or do you need a second product for that?",[42,896,897,900],{},[26,898,899],{},"Incident management"," Is there a real incident workflow with multiple status stages, or just a simple \"down\u002Fup\"?",[42,902,903,906],{},[26,904,905],{},"Self-hosted option"," Can the software run on your own servers — relevant for data sovereignty and regulated industries?",[42,908,909,912],{},[26,910,911],{},"GDPR \u002F server location"," Where are the servers, and is compliant operation possible without third-country data transfer?",[42,914,915,918],{},[26,916,917],{},"Free tier"," Is there a permanently free entry point, or does usage start as a paid plan?",[42,920,921,924],{},[26,922,923],{},"Price transparency and feature gating"," Are basic functions like custom branding or private pages included, or are they artificially withheld behind expensive tiers and add-ons?",[42,926,927,930],{},[26,928,929],{},"Custom branding"," Can you use your own logo, colors, and domain without an upcharge?",[16,932,933],{},"Custom branding and feature gating deserve particular attention. With many vendors, the very functions that make a statuspage look professional — custom CSS, private pages, white-label — only become available in high tiers. That pushes the price up quickly.",[11,935,937],{"id":936},"quick-overview-all-statuspage-tools-compared","Quick Overview: All Statuspage Tools Compared",[16,939,940],{},"The table below summarizes the key figures. The entry price refers to the cheapest permanently usable plan (free, where available).",[204,942,943,964],{},[207,944,945],{},[210,946,947,949,952,955,958,961],{},[213,948,622],{},[213,950,951],{},"Origin",[213,953,954],{},"Type",[213,956,957],{},"Self-Hosted",[213,959,960],{},"Monitoring Incl.",[213,962,963],{},"Entry Price",[220,965,966,986,1005,1021,1038,1055,1071,1088,1105,1122,1140,1157,1172,1189],{},[210,967,968,972,975,978,981,983],{},[225,969,970],{},[26,971,635],{},[225,973,974],{},"Germany",[225,976,977],{},"Monitoring + Statuspage + Incidents",[225,979,980],{},"Yes",[225,982,980],{},[225,984,985],{},"€0 (Smart)",[210,987,988,991,994,997,1000,1002],{},[225,989,990],{},"Atlassian Statuspage",[225,992,993],{},"Australia\u002FUSA",[225,995,996],{},"Statuspage only",[225,998,999],{},"No",[225,1001,999],{},[225,1003,1004],{},"$0",[210,1006,1007,1009,1012,1015,1017,1019],{},[225,1008,701],{},[225,1010,1011],{},"Czech Republic",[225,1013,1014],{},"Monitoring + Logging + Statuspage",[225,1016,999],{},[225,1018,980],{},[225,1020,1004],{},[210,1022,1023,1026,1029,1032,1034,1036],{},[225,1024,1025],{},"Instatus",[225,1027,1028],{},"USA",[225,1030,1031],{},"Statuspage + Monitoring",[225,1033,999],{},[225,1035,980],{},[225,1037,1004],{},[210,1039,1040,1043,1046,1049,1051,1053],{},[225,1041,1042],{},"Hyperping",[225,1044,1045],{},"France",[225,1047,1048],{},"Monitoring + Statuspage",[225,1050,999],{},[225,1052,980],{},[225,1054,1004],{},[210,1056,1057,1059,1062,1065,1067,1069],{},[225,1058,690],{},[225,1060,1061],{},"Slovakia",[225,1063,1064],{},"Monitoring + Basic Statuspage",[225,1066,999],{},[225,1068,980],{},[225,1070,1004],{},[210,1072,1073,1076,1079,1081,1083,1085],{},[225,1074,1075],{},"Uptime Kuma",[225,1077,1078],{},"Open Source",[225,1080,1064],{},[225,1082,980],{},[225,1084,980],{},[225,1086,1087],{},"free",[210,1089,1090,1093,1095,1098,1100,1102],{},[225,1091,1092],{},"incident.io",[225,1094,1028],{},[225,1096,1097],{},"Incident Management",[225,1099,999],{},[225,1101,999],{},[225,1103,1104],{},"Free (Basic)",[210,1106,1107,1110,1112,1115,1117,1119],{},[225,1108,1109],{},"iLert",[225,1111,974],{},[225,1113,1114],{},"Alerting + Statuspage",[225,1116,999],{},[225,1118,999],{},[225,1120,1121],{},"Free (5 users)",[210,1123,1124,1127,1130,1133,1135,1137],{},[225,1125,1126],{},"Oh Dear",[225,1128,1129],{},"Belgium",[225,1131,1132],{},"Website Health Check",[225,1134,999],{},[225,1136,980],{},[225,1138,1139],{},"€15",[210,1141,1142,1144,1147,1150,1152,1155],{},[225,1143,646],{},[225,1145,1146],{},"Latvia (OSS)",[225,1148,1149],{},"Cron\u002FHeartbeat Monitoring",[225,1151,980],{},[225,1153,1154],{},"partial",[225,1156,1004],{},[210,1158,1159,1162,1164,1166,1168,1170],{},[225,1160,1161],{},"HetrixTools",[225,1163,1028],{},[225,1165,1064],{},[225,1167,999],{},[225,1169,980],{},[225,1171,625],{},[210,1173,1174,1177,1179,1182,1184,1186],{},[225,1175,1176],{},"Uptime.com",[225,1178,1028],{},[225,1180,1181],{},"Enterprise Monitoring",[225,1183,999],{},[225,1185,980],{},[225,1187,1188],{},"from $9 + $13",[210,1190,1191,1194,1197,1200,1202,1204],{},[225,1192,1193],{},"PingPing",[225,1195,1196],{},"Netherlands",[225,1198,1199],{},"Uptime Monitoring",[225,1201,999],{},[225,1203,980],{},[225,1205,1206],{},"5 sites €6",[16,1208,1209],{},"LIVCK sits at the top of this list because it is the only vendor that bundles monitoring, statuspage, and incident management into one tool, is available both self-hosted and (soon) as a cloud service, and comes from Germany. The honest reasoning for that follows directly in the next section — after which we look at each tool individually.",[11,1211,1213],{"id":1212},"the-tools-in-detail","The Tools in Detail",[65,1215,1217],{"id":1216},"_1-livck-all-in-one-from-germany","1. LIVCK — All-in-One from Germany",[16,1219,1220,1221,1223],{},"LIVCK comes from Germany and combines monitoring, statuspage, and incident management in one tool. That is the essential difference from most other entries on this list: you need no separate monitoring product to detect outages and no second tool to communicate them. For monitoring, LIVCK covers HTTP(S), TCP\u002Fport, ping, DNS, SSL, heartbeat (ideal for cron jobs and background processes), and manual checks (via API). An incident is only triggered after the majority of independent probe locations have confirmed the outage — which noticeably reduces false alarms during brief network hiccups. A dedicated guide describes how solid ",[20,1222,23],{"href":22}," works in detail.",[16,1225,1226],{},"For incident management, LIVCK offers announcements, maintenance windows, and incidents with a full status workflow, auto-detection, and postmortems. Outage linking merges several affected services that share a common root cause into a single incident, instead of making you maintain five parallel notices. The decisive point on the statuspage side: custom branding (logo, colors, own domain), private pages, newsletter and subscribers, an uptime calendar, SLA display, PWA, badges, and multi-language are included in every plan at no extra cost. With many competitors, those exact building blocks cost extra.",[16,1228,1229,1230,1233],{},"LIVCK is the only German vendor with self-hosted ",[26,1231,1232],{},"and"," cloud. Self-hosted runs via Docker Compose and is installed in minutes:",[102,1235,1237],{"className":104,"code":1236,"language":106,"meta":107,"style":107},"curl -fsSL https:\u002F\u002Fget.livck.com -o docker-compose.yml\ndocker compose up -d\n",[82,1238,1239,1254],{"__ignoreMap":107},[111,1240,1241,1243,1246,1249,1251],{"class":113,"line":114},[111,1242,84],{"class":124},[111,1244,1245],{"class":128}," -fsSL",[111,1247,1248],{"class":139}," https:\u002F\u002Fget.livck.com",[111,1250,164],{"class":128},[111,1252,1253],{"class":139}," docker-compose.yml\n",[111,1255,1256,1259,1262,1265],{"class":113,"line":121},[111,1257,1258],{"class":124},"docker",[111,1260,1261],{"class":139}," compose",[111,1263,1264],{"class":139}," up",[111,1266,1267],{"class":128}," -d\n",[16,1269,1270,1271,1275,1276,1280],{},"The self-hosted license starts at €0 (Smart: 20 monitors, 5 categories, 1 member, 100 subscribers). Above that are Starter (€9.90\u002Fmo or €99\u002Fyear, 80 monitors, 2 members, 500 subscribers), Business (€39.90\u002Fmo or €399\u002Fyear, 150 monitors, 10 members, 3 pages, 1,000 subscribers), and Extended (€99.90\u002Fmo or €999\u002Fyear, 300 monitors, 25 members, 6 pages, 5,000 subscribers). A Hetzner Cloud CX22 from around €4.75\u002Fmo is already enough as a server — the ",[20,1272,1274],{"href":757,"rel":1273},[759],"Hetzner recommendation link"," leads to the right plan. One rule of thumb holds regardless of vendor: the statuspage should not run on the same infrastructure as the monitored systems, otherwise both fail at once when it matters. More on this in the ",[20,1277,1279],{"href":1278},"\u002Fen\u002Fguides\u002Fself-hosted-statuspage","self-hosted statuspage guide",".",[16,1282,1283,1284,1289,1290,1280],{},"The cloud variant is in public beta, reachable via the waitlist; the Free plan costs €0 (20 services, 120s interval, 1 page), followed by Solo (€19\u002Fmo), Team (€49\u002Fmo), and Business (€119\u002Fmo, all net). Anyone who wants full control today uses self-hosted or the managed service. An honest limitation: self-hosted assumes you run a server and apply updates (even if an auto-updater helps). If you would rather not, take the cloud (public beta) or the managed service. Details and installation are in the ",[20,1285,1288],{"href":1286,"rel":1287},"https:\u002F\u002Fdocs.livck.cloud",[759],"LIVCK documentation"," and on the ",[20,1291,1294],{"href":1292,"rel":1293},"https:\u002F\u002Flivck.cloud\u002Fen",[759],"statuspage product page",[65,1296,1298],{"id":1297},"_2-atlassian-statuspage","2. Atlassian Statuspage",[16,1300,1301,1302,1305,1306,1310],{},"Atlassian Statuspage hails from Australia\u002FUSA and is the best-known name on the market — but pure statuspage software ",[26,1303,1304],{},"without its own monitoring",". So you necessarily need a second tool to detect outages. Plans range from Free ($0) through Hobby ($29), Startup ($99), and Business ($399) up to Enterprise ($1,499). Its strength lies in the mature subscriber and incident workflow. The main catch: custom CSS\u002FHTML\u002FJS only arrives at Business ($399), private pages at $79. Anyone who needs branding and private pages quickly lands in the three-digit monthly range. The full ",[20,1307,1309],{"href":1308},"\u002Fen\u002Fatlassian-alternative","LIVCK vs. Atlassian comparison"," is available as its own page.",[65,1312,1314],{"id":1313},"_3-better-stack","3. Better Stack",[16,1316,1317,1318,1280],{},"Better Stack from the Czech Republic combines monitoring, logging, and statuspage and is cleanly built on the technical side. Entry is possible with Free ($0); it becomes paid from $34 per responder plus add-ons. That add-on logic is precisely the weakness: custom CSS costs $15, private pages $50 — each per page and month. With several statuspages, that adds up. Self-hosting is not possible. If you want to work through the modular pricing structure, you will find details in the ",[20,1319,1321],{"href":1320},"\u002Fen\u002Fbetter-stack-alternative","LIVCK vs. Better Stack comparison",[65,1323,1325],{"id":1324},"_4-instatus","4. Instatus",[16,1327,1328,1329,1333],{},"Instatus from the USA delivers the most visually appealing statuspages on the market and now also brings monitoring. The free plan ($0) is generous, Pro costs $20. The limitation: custom CSS\u002FJS only arrives in the Business plan at $300 — a big jump. Self-hosting is not provided, and the servers are in the USA. For a beautiful, quickly set up showcase statuspage, Instatus is a good choice; the ",[20,1330,1332],{"href":1331},"\u002Fen\u002Finstatus-alternative","LIVCK vs. Instatus comparison"," examines the differences in detail.",[65,1335,1337],{"id":1336},"_5-hyperping","5. Hyperping",[16,1339,1340,1341,1345],{},"Hyperping from France connects monitoring and statuspage in a tidy product. Plans range from Free ($0) through Hobby ($14), Basic ($29), and Pro ($89) up to Business ($199). It is easy to operate and the feature set is solid. The limitation from a German perspective: no self-hosting and no German servers, which complicates matters for GDPR-sensitive projects. The ",[20,1342,1344],{"href":1343},"\u002Fen\u002Fhyperping-alternative","LIVCK vs. Hyperping comparison"," puts that into context.",[65,1347,1349],{"id":1348},"_6-uptimerobot","6. UptimeRobot",[16,1351,1352,1353,1280],{},"UptimeRobot from Slovakia is a classic for cheap basic monitoring with a simple statuspage. The free plan ($0) is enough for first steps, above it sit Solo ($8), Team ($34), and Enterprise ($64). Its strength is the good value for money in pure monitoring. The weakness: custom design for the statuspage only arrives at Team ($34), and incident management remains rudimentary. More in the ",[20,1354,1355],{"href":721},"LIVCK vs. UptimeRobot comparison",[65,1357,1359],{"id":1358},"_7-uptime-kuma","7. Uptime Kuma",[16,1361,1362,1363,1280],{},"Uptime Kuma is the most popular open-source monitoring tool and fully free to self-host. It monitors numerous check types and ships a simple statuspage. For hobby projects and homelabs it is an excellent choice. The limits become visible in professional use: no real incident management with a status workflow, no newsletter, no statuspage designer, and it is designed for a single user — teams and granular permissions are missing. Where Uptime Kuma ends and a professional tool begins is shown in the ",[20,1364,1366],{"href":1365},"\u002Fen\u002Fuptime-kuma-alternative","LIVCK vs. Uptime Kuma comparison",[65,1368,1370],{"id":1369},"_8-incidentio","8. incident.io",[16,1372,1373,1374,1280],{},"incident.io from the USA is really a pure incident-management platform with strong Slack integration and a statuspage as a complement. Plans begin at Basic (Free), above it Team ($19\u002Fuser), Pro ($25\u002Fuser), and Enterprise. Its strength is the mature incident workflow for larger engineering teams. Weaknesses: per-user pricing gets expensive as teams grow, there is no monitoring of its own at all, and on-call is a separate, paid module. Details in the ",[20,1375,1377],{"href":1376},"\u002Fen\u002Fincident-io-alternative","LIVCK vs. incident.io comparison",[65,1379,1381],{"id":1380},"_9-ilert","9. iLert",[16,1383,1384,1385,1389],{},"iLert, like LIVCK, comes from Germany and specializes in alerting and on-call, with a statuspage as an add-on. The free plan covers up to 5 users, above it there are Pro\u002FScale with dynamic per-user pricing as well as Enterprise. Its strength is the German location and the well-thought-out alerting. The limitation: no monitoring of its own in the classic sense, and both statuspage and heartbeat checks run on add-on pricing. The ",[20,1386,1388],{"href":1387},"\u002Fen\u002Filert-alternative","LIVCK vs. iLert comparison"," shows where the two German vendors differ.",[65,1391,1393],{"id":1392},"_10-oh-dear","10. Oh Dear",[16,1395,1396,1397,1280],{},"Oh Dear from Belgium is a website health-check tool that goes beyond pure uptime (such as broken-link checks and certificate monitoring) and brings a statuspage along. Plans are €15, €50, and €140. Its strength is the broad health-check coverage for individual websites. Weaknesses: no free tier and no self-hosting. More in the ",[20,1398,1400],{"href":1399},"\u002Fen\u002Fohdear-alternative","LIVCK vs. Oh Dear comparison",[65,1402,1404],{"id":1403},"_11-healthchecksio","11. Healthchecks.io",[16,1406,1407,1408,1411,1412,1415],{},"Healthchecks.io from Latvia is open source and specializes in cron and heartbeat monitoring — that is, watching background jobs, backups, and scheduled tasks. The Hobbyist plan is free ($0), Business costs $20, Business Plus $80; in addition, you can self-host the OSS variant. Its strength is the excellent coverage of cron checks. A clear limit: there is ",[26,1409,1410],{},"no statuspage"," in the actual sense and no broader check types. Strong for pure job monitoring, not intended as a statuspage solution — the ",[20,1413,1414],{"href":713},"LIVCK vs. Healthchecks.io comparison"," explains the distinction.",[65,1417,1419],{"id":1418},"_12-hetrixtools","12. HetrixTools",[16,1421,1422,1423,1280],{},"HetrixTools from the USA offers monitoring with a simple statuspage. Plans range from Free through Professional ($9.95) and Business ($19.95) up to Enterprise ($49.95). Its strength is the cheap monitoring including blacklist monitoring. The limitations: white-label only arrives at $49.95, and real incident management is missing. Details in the ",[20,1424,1426],{"href":1425},"\u002Fen\u002Fhetrixtools-alternative","LIVCK vs. HetrixTools comparison",[65,1428,1430],{"id":1429},"_13-uptimecom-and-pingping","13. Uptime.com and PingPing",[16,1432,1433,1434,1436,1437,598,1441,1443,1444,1280],{},"We cover two tools briefly because they sit more at the edge of the statuspage topic. ",[26,1435,1176],{}," from the USA is an enterprise monitoring platform; monitoring starts at $9, the statuspage is billed separately from $13. There is no free tier, and the separation of monitoring and statuspage makes the calculation laborious — details in the ",[20,1438,1440],{"href":1439},"\u002Fen\u002Fuptime-com-alternative","LIVCK vs. Uptime.com comparison",[26,1442,1193],{}," from the Netherlands is pure uptime monitoring, tiered by sites: 5 sites €6, 25 sites €30, 100 sites €90. Here too, a free tier and real incident management are missing — see the ",[20,1445,1447],{"href":1446},"\u002Fen\u002Fpingping-alternative","LIVCK vs. PingPing comparison",[11,1449,1451],{"id":1450},"which-tool-for-whom","Which Tool for Whom?",[16,1453,1454],{},"There is no single best statuspage software — it depends on the use case. A guide for orientation:",[204,1456,1457,1467],{},[207,1458,1459],{},[210,1460,1461,1464],{},[213,1462,1463],{},"Use case",[213,1465,1466],{},"Recommendation",[220,1468,1469,1476,1483,1490,1497,1504],{},[210,1470,1471,1474],{},[225,1472,1473],{},"German company, GDPR, regulated industry",[225,1475,635],{},[210,1477,1478,1481],{},[225,1479,1480],{},"Pure OSS hobby with no incident ambitions",[225,1482,1075],{},[210,1484,1485,1488],{},[225,1486,1487],{},"Cron\u002Fheartbeat checks only",[225,1489,646],{},[210,1491,1492,1495],{},[225,1493,1494],{},"Pure incident management with a Slack focus",[225,1496,1092],{},[210,1498,1499,1502],{},[225,1500,1501],{},"Prettiest statuspage as a pure showcase",[225,1503,1025],{},[210,1505,1506,1509],{},[225,1507,1508],{},"Cheap basic monitoring",[225,1510,690],{},[16,1512,1513,1514,1518],{},"Anyone operating in Germany or in a regulated industry (data centers, finance, healthcare, public sector) who values data sovereignty will hardly get around a self-hosted or German solution — this is where LIVCK plays out its GDPR strengths, which the guide on the ",[20,1515,1517],{"href":1516},"\u002Fen\u002Fguides\u002Fgdpr-statuspage","GDPR-compliant statuspage"," explores in depth. If you only want to monitor a homelab, Uptime Kuma serves you well. If it is solely about backups and cron jobs, Healthchecks.io is the specialist tool. If you primarily need an incident process for a large engineering team with Slack, incident.io is worth a look. And anyone simply looking for a pretty public status page without deep monitoring reaches the goal quickly with Instatus.",[11,1520,1522],{"id":1521},"frequently-asked-questions-about-statuspage-tools","Frequently Asked Questions About Statuspage Tools",[16,1524,1525,1528],{},[26,1526,1527],{},"What is the best statuspage software in 2026?"," It depends on your needs. For German companies with GDPR requirements and a desire for an all-in-one solution, LIVCK is the obvious choice because it combines monitoring, statuspage, and incident management without feature gating. For pure hobby projects, Uptime Kuma is the best free option.",[16,1530,1531,1534],{},[26,1532,1533],{},"What does a statuspage cost?"," The range is enormous. Free plans exist at LIVCK (Smart €0), Atlassian, Better Stack, Instatus, Hyperping, and UptimeRobot. Professional features cost, depending on the vendor, between single-digit monthly amounts and several hundred dollars — Atlassian, for instance, charges $399 for custom CSS, Instatus $300.",[16,1536,1537,1540],{},[26,1538,1539],{},"Is there free statuspage software?"," Yes, several. Uptime Kuma is fully free and open source. LIVCK Smart, Atlassian Free, Instatus Free, and others offer permanently free entry plans.",[16,1542,1543,1546],{},[26,1544,1545],{},"Which statuspage tools include monitoring?"," LIVCK, Better Stack, Instatus, Hyperping, UptimeRobot, Uptime Kuma, and HetrixTools bring their own monitoring. Atlassian Statuspage, incident.io, and iLert do not offer full-fledged monitoring of their own.",[16,1548,1549,1552],{},[26,1550,1551],{},"Which statuspage solution is GDPR-compliant and from Germany?"," LIVCK and iLert are German vendors. LIVCK is GDPR by design — through self-hosting in your own network or operation on German servers, data transfer to third countries can be avoided entirely.",[16,1554,1555,1558],{},[26,1556,1557],{},"What is the best open-source statuspage?"," For simple use cases, Uptime Kuma. Anyone wanting to combine open-source self-determination with professional incident management and a statuspage designer is better served by the self-hosted variant of LIVCK.",[16,1560,1561,1564,1565,1567],{},[26,1562,1563],{},"What is the best Atlassian Statuspage alternative?"," It depends on budget and requirements. If you want monitoring included and no $399 hurdle for custom CSS, the ",[20,1566,1309],{"href":1308}," offers a detailed head-to-head.",[16,1569,1570,1573],{},[26,1571,1572],{},"What distinguishes a statuspage from a monitoring tool?"," Monitoring checks technically whether a system is reachable and alerts your team. The statuspage communicates the status outward to users and customers. Both complement each other; separate tools mean double the cost and friction at the interface.",[16,1575,1576,1579],{},[26,1577,1578],{},"Which statuspage tool can be self-hosted?"," Self-hosting is offered by LIVCK (Docker Compose), Uptime Kuma, and Healthchecks.io (both open source). Commercial SaaS vendors like Atlassian, Better Stack, or Instatus do not offer self-hosting.",[16,1581,1582,1585],{},[26,1583,1584],{},"What should you watch for when choosing?"," The seven criteria listed above — especially feature gating: check whether custom branding, private pages, and multi-language are included in the chosen plan or have to be bought expensively on top.",[16,1587,1588,1591],{},[26,1589,1590],{},"Which statuspage suits small teams and startups?"," For a tight budget with a monitoring need, LIVCK (Smart €0 or Starter €9.90\u002Fmo), UptimeRobot, or Hyperping are good options. Watch the subscriber and member limits of the respective plans.",[16,1593,1594,1597],{},[26,1595,1596],{},"Do I need a separate monitoring tool for a statuspage?"," Only if the statuspage tool brings no monitoring of its own — as with Atlassian Statuspage, for example. All-in-one solutions like LIVCK make a second tool unnecessary.",[11,1599,772],{"id":771},[16,1601,1602],{},"The statuspage tool market in 2026 is broad but clearly structured. Pure statuspage vendors like Atlassian deliver mature workflows but require separate monitoring and pull important functions behind expensive tiers. Specialists like Healthchecks.io or incident.io are strong in their domain but do not cover the full spectrum. Open source like Uptime Kuma is ideal for hobby use but hits its limits in team deployment.",[16,1604,1605],{},"For German companies with GDPR requirements, a desire for data sovereignty, and an all-in-one solution without feature gating, LIVCK is the most consistent choice: monitoring, statuspage, and incident management in one tool, self-hosted from €0 and cloud in preparation, as the only German vendor with both operating modes. The honest caveat remains: anyone who would rather not run a server waits for the cloud or chooses the managed service — and anyone monitoring only a homelab or pure cron jobs travels lighter with Uptime Kuma or Healthchecks.io. Which tool is best for you is ultimately decided by your use case — and you now hold the criteria for that decision in your hands.",[812,1607,1608],{},"html pre.shiki code .sScJk, html code.shiki .sScJk{--shiki-default:#6F42C1;--shiki-dark:#B392F0}html pre.shiki code .sj4cs, html code.shiki .sj4cs{--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .sZZnC, html code.shiki .sZZnC{--shiki-default:#032F62;--shiki-dark:#9ECBFF}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":107,"searchDepth":121,"depth":121,"links":1610},[1611,1612,1613,1614,1629,1630,1631],{"id":861,"depth":121,"text":862},{"id":882,"depth":121,"text":883},{"id":936,"depth":121,"text":937},{"id":1212,"depth":121,"text":1213,"children":1615},[1616,1617,1618,1619,1620,1621,1622,1623,1624,1625,1626,1627,1628],{"id":1216,"depth":331,"text":1217},{"id":1297,"depth":331,"text":1298},{"id":1313,"depth":331,"text":1314},{"id":1324,"depth":331,"text":1325},{"id":1336,"depth":331,"text":1337},{"id":1348,"depth":331,"text":1349},{"id":1358,"depth":331,"text":1359},{"id":1369,"depth":331,"text":1370},{"id":1380,"depth":331,"text":1381},{"id":1392,"depth":331,"text":1393},{"id":1403,"depth":331,"text":1404},{"id":1418,"depth":331,"text":1419},{"id":1429,"depth":331,"text":1430},{"id":1450,"depth":121,"text":1451},{"id":1521,"depth":121,"text":1522},{"id":771,"depth":121,"text":772},"Comparison","The best statuspage tools in 2026 compared: LIVCK, Atlassian, Better Stack, Instatus, UptimeRobot & more — features, pricing, self-hosting, data privacy.",[1635,1637,1639,1641,1643,1645,1647,1649,1651,1653,1655,1657],{"question":1527,"answer":1636},"It depends on your needs. For German companies with GDPR requirements and a desire for an all-in-one solution, LIVCK is the obvious choice because it combines monitoring, statuspage, and incident management without feature gating. For pure hobby projects, Uptime Kuma is the best free option.",{"question":1533,"answer":1638},"The range is enormous. Free plans exist at LIVCK (Smart €0), Atlassian, Better Stack, Instatus, Hyperping, and UptimeRobot. Professional features cost, depending on the vendor, between single-digit monthly amounts and several hundred dollars — Atlassian, for instance, charges $399 for custom CSS, Instatus $300.",{"question":1539,"answer":1640},"Yes, several. Uptime Kuma is fully free and open source. LIVCK Smart, Atlassian Free, Instatus Free, and others offer permanently free entry plans.",{"question":1545,"answer":1642},"LIVCK, Better Stack, Instatus, Hyperping, UptimeRobot, Uptime Kuma, and HetrixTools bring their own monitoring. Atlassian Statuspage, incident.io, and iLert do not offer full-fledged monitoring of their own.",{"question":1551,"answer":1644},"LIVCK and iLert are German vendors. LIVCK is GDPR by design — through self-hosting in your own network or operation on German servers, data transfer to third countries can be avoided entirely.",{"question":1557,"answer":1646},"For simple use cases, Uptime Kuma. Anyone wanting to combine open-source self-determination with professional incident management and a statuspage designer is better served by the self-hosted variant of LIVCK.",{"question":1563,"answer":1648},"It depends on budget and requirements. If you want monitoring included and no $399 hurdle for custom CSS, the LIVCK vs. Atlassian comparison offers a detailed head-to-head.",{"question":1572,"answer":1650},"Monitoring checks technically whether a system is reachable and alerts your team. The statuspage communicates the status outward to users and customers. Both complement each other; separate tools mean double the cost and friction at the interface.",{"question":1578,"answer":1652},"Self-hosting is offered by LIVCK (Docker Compose), Uptime Kuma, and Healthchecks.io (both open source). Commercial SaaS vendors like Atlassian, Better Stack, or Instatus do not offer self-hosting.",{"question":1584,"answer":1654},"The seven criteria listed above — especially feature gating: check whether custom branding, private pages, and multi-language are included in the chosen plan or have to be bought expensively on top.",{"question":1590,"answer":1656},"For a tight budget with a monitoring need, LIVCK (Smart €0 or Starter €9.90\u002Fmo), UptimeRobot, or Hyperping are good options. Watch the subscriber and member limits of the respective plans.",{"question":1596,"answer":1658},"Only if the statuspage tool brings no monitoring of its own — as with Atlassian Statuspage, for example. All-in-one solutions like LIVCK make a second tool unnecessary.",{},"\u002Fguides\u002Fen\u002Fbest-statuspage-tools","beste-statuspage-tools","2026-06-24",14,[1665,1666,1667],"atlassian","better-stack","instatus",[1669,850,848],"what-is-a-statuspage",{"title":856,"description":1633},"guides\u002Fen\u002Fbest-statuspage-tools","SFe1bjmvcCndJkewS3LT5m1vEtws4BMYD1iNxOkLdeU",{"id":1674,"title":1675,"body":1676,"category":1097,"description":2234,"extension":836,"faq":837,"meta":2235,"navigation":334,"path":2236,"peerSlug":849,"publishedAt":1662,"readingTime":2237,"relatedComparisons":2238,"relatedGuides":2241,"seo":2243,"stem":2244,"updatedAt":837,"__hash__":2245},"guides\u002Fguides\u002Fen\u002Fincident-management.md","Incident Management: Process, Roles and Communication",{"type":8,"value":1677,"toc":2212},[1678,1682,1685,1688,1691,1695,1698,1718,1721,1725,1728,1732,1738,1742,1745,1749,1752,1756,1767,1771,1774,1778,1781,1784,1859,1862,1865,1909,1921,1925,1928,1958,1961,1965,1968,1971,1976,1980,1983,1989,1995,1998,2024,2033,2037,2040,2065,2068,2071,2075,2078,2098,2105,2109,2112,2121,2125,2128,2146,2159,2163,2166,2204,2206,2209],[11,1679,1681],{"id":1680},"what-is-incident-management","What Is Incident Management?",[16,1683,1684],{},"Incident management is the structured process a team uses to detect an unplanned service disruption, coordinate its repair and learn from it afterward. An incident is an unplanned interruption or a noticeable degradation in the quality of a service — anything from a completely unreachable application to a checkout page that has slowed to a crawl. The primary goal of incident management is not to immediately find the deepest root cause, but to restore the service as quickly as possible.",[16,1686,1687],{},"This definition stays close to the ITIL understanding, where incident management is its own discipline within IT service management. You don't need to implement ITIL in detail to benefit from it. What matters is that everyone on the team means the same thing by \"an incident,\" knows who does what during a disruption, and that customer communication doesn't happen on the fly.",[16,1689,1690],{},"Incident management in plain terms: it's the emergency plan for your digital services. When something breaks, the process makes sure the right people come together quickly, the damage is contained, customers are informed honestly, and the team learns from the event afterward — instead of starting from scratch every time.",[65,1692,1694],{"id":1693},"distinguishing-incident-problem-and-service-request","Distinguishing Incident, Problem and Service Request",[16,1696,1697],{},"Three terms often get blurred together in everyday work, but they mean different things:",[39,1699,1700,1706,1712],{},[42,1701,1702,1705],{},[26,1703,1704],{},"Incident"," is the active disruption. The focus is on restoration. Example: the API has been returning 500 errors for the past ten minutes.",[42,1707,1708,1711],{},[26,1709,1710],{},"Problem"," is the underlying cause behind one or more incidents. The focus is on permanently eliminating the cause. Example: a memory leak that repeatedly takes the API down.",[42,1713,1714,1717],{},[26,1715,1716],{},"Service request"," is a planned, standard request with no outage involved — such as the wish for a new user account or more storage. There is nothing to restore here.",[16,1719,1720],{},"This distinction is more than nitpicking. An incident is handled with high urgency, a problem with care and analytical depth, a service request through a calm, planned workflow. Throw everything into the same bucket and you either treat routine requests as emergencies or let real outages drown among ordinary tickets.",[11,1722,1724],{"id":1723},"the-incident-lifecycle","The Incident Lifecycle",[16,1726,1727],{},"Every incident goes through the same phases, whether it's done in five minutes or only after hours of work. A clear lifecycle makes sure nobody skips steps, especially under pressure.",[65,1729,1731],{"id":1730},"step-1-detection","Step 1: Detection",[16,1733,1734,1735,1737],{},"It all begins with detection. Ideally, your monitoring reports the disruption before the first customer notices it. The earlier the detection, the shorter the total downtime ends up being. How to monitor services reliably and which check types exist is covered in detail in the ",[20,1736,23],{"href":22}," guide. A disruption that only comes to light through a customer complaint has usually already done damage.",[65,1739,1741],{"id":1740},"step-2-triage-and-classification","Step 2: Triage and Classification",[16,1743,1744],{},"Once an alert exists, triage follows. This is where the severity is assessed, the scope is estimated (Who is affected? Which functions?) and a decision is made about whether a formal incident process is even needed. Not every alert is a major incident. Triage prevents small things from triggering the whole machinery while real emergencies slip through.",[65,1746,1748],{"id":1747},"step-3-response","Step 3: Response",[16,1750,1751],{},"In the response phase, the team forms up. Roles are assigned, the investigation begins, first hypotheses are tested. In parallel — and this is crucial — communication starts, both internally and externally. Customers would rather wait on an honest \"we're investigating\" message than hear nothing at all.",[65,1753,1755],{"id":1754},"step-4-mitigation-and-resolution","Step 4: Mitigation and Resolution",[16,1757,1758,1759,1762,1763,1766],{},"There is an important distinction to make here. ",[26,1760,1761],{},"Mitigation"," means addressing the symptom and making the service available again — for instance through a rollback, a restart or by rerouting traffic. ",[26,1764,1765],{},"Resolution"," in the strict sense means permanently eliminating the actual cause. In practice, mitigation comes first: the service is running again, customers are taken care of. The clean root-cause fix often follows later, calmly, frequently as part of downstream problem management. Confusing these two steps leads teams to declare an incident \"solved\" too early.",[65,1768,1770],{"id":1769},"step-5-follow-up-and-post-mortem","Step 5: Follow-Up and Post-Mortem",[16,1772,1773],{},"After restoration, the incident is technically over, but the process is not. The follow-up in the form of a post-mortem records what happened, why, and what needs to change. This step is the one most often skipped — and that is exactly why incidents repeat.",[11,1775,1777],{"id":1776},"severity-and-status-levels","Severity and Status Levels",[16,1779,1780],{},"Severity and public status levels describe two different things: severity says internally how bad it is; the status level says externally where you currently stand in the handling process.",[16,1782,1783],{},"A common severity scale looks like this:",[204,1785,1786,1801],{},[207,1787,1788],{},[210,1789,1790,1793,1795,1798],{},[213,1791,1792],{},"Severity",[213,1794,218],{},[213,1796,1797],{},"Example",[213,1799,1800],{},"Response",[220,1802,1803,1817,1831,1845],{},[210,1804,1805,1808,1811,1814],{},[225,1806,1807],{},"SEV1",[225,1809,1810],{},"Critical, complete or broad outage",[225,1812,1813],{},"Platform entirely unreachable",[225,1815,1816],{},"Immediate, all-hands",[210,1818,1819,1822,1825,1828],{},[225,1820,1821],{},"SEV2",[225,1823,1824],{},"Significant degradation",[225,1826,1827],{},"Some users or core functions affected",[225,1829,1830],{},"Urgent, dedicated team",[210,1832,1833,1836,1839,1842],{},[225,1834,1835],{},"SEV3",[225,1837,1838],{},"Minor degradation, workaround available",[225,1840,1841],{},"A single non-critical feature impaired",[225,1843,1844],{},"Soon, regular workflow",[210,1846,1847,1850,1853,1856],{},[225,1848,1849],{},"SEV4\u002FSEV5",[225,1851,1852],{},"Cosmetic or trivial",[225,1854,1855],{},"Typo, slight rendering glitch",[225,1857,1858],{},"In the backlog, by priority",[16,1860,1861],{},"Important: severity is not the same as priority. Severity describes the degree of impact, priority the order of handling. A SEV2 incident can take a higher priority than another SEV2 depending on business context — for example when an important customer is affected.",[16,1863,1864],{},"The public status levels of a status page follow their own well-established scheme:",[204,1866,1867,1876],{},[207,1868,1869],{},[210,1870,1871,1874],{},[213,1872,1873],{},"Status",[213,1875,218],{},[220,1877,1878,1886,1894,1901],{},[210,1879,1880,1883],{},[225,1881,1882],{},"Investigating",[225,1884,1885],{},"Disruption detected, cause still unclear, investigation underway",[210,1887,1888,1891],{},[225,1889,1890],{},"Identified",[225,1892,1893],{},"Cause found, fix being applied",[210,1895,1896,1898],{},[225,1897,834],{},[225,1899,1900],{},"Fix rolled out, team watching for stability",[210,1902,1903,1906],{},[225,1904,1905],{},"Resolved",[225,1907,1908],{},"Service fully restored",[16,1910,1911,1912,1915,1916,1920],{},"On top of this comes ",[26,1913,1914],{},"Maintenance"," as its own type — a planned maintenance window is not an outage and should not be communicated as an incident. How to drive these levels cleanly to the outside is explored further in the ",[20,1917,1919],{"href":1918},"\u002Fen\u002Fguides\u002Fstatuspage-best-practices","status page best practices"," guide.",[11,1922,1924],{"id":1923},"roles-during-an-incident","Roles During an Incident",[16,1926,1927],{},"In a larger incident, it isn't enough for \"everyone to help somehow.\" Clear roles prevent chaos and duplicated effort. For small disruptions, one person can hold several roles; in a SEV1, they should be separate.",[39,1929,1930,1940,1946,1952],{},[42,1931,1932,1935,1936,1939],{},[26,1933,1934],{},"Incident Commander (IC):"," coordinates the entire incident, makes decisions and delegates. The IC deliberately does ",[34,1937,1938],{},"not"," debug — they keep the overview instead of getting lost in the technical detail. Their job is steering, not troubleshooting.",[42,1941,1942,1945],{},[26,1943,1944],{},"Communications \u002F Comms Lead:"," owns all communication, internally to stakeholders and externally to customers, including the status page updates. This keeps the technical crew free to work undisturbed.",[42,1947,1948,1951],{},[26,1949,1950],{},"Operations \u002F Tech Lead:"," runs the technical investigation and implements the fix. This role is deep in the code, the logs and the infrastructure.",[42,1953,1954,1957],{},[26,1955,1956],{},"Scribe:"," records the timeline — who did or noticed what, and when. This log later becomes the basis of the post-mortem and, along the way, takes a significant load off everyone's memory.",[16,1959,1960],{},"What an incident commander actually does can be summed up in one sentence: they are the calm point that keeps the process moving, drives decisions and makes sure every role knows its task — without chasing the disruption at the keyboard themselves.",[11,1962,1964],{"id":1963},"escalation-on-call-and-alerting","Escalation, On-Call and Alerting",[16,1966,1967],{},"For an incident to reach anyone at all, you need an on-call duty and an escalation chain. On-call means that at any given time a defined person is responsible for incoming alerts — usually in a rotation, say weekly, so the load is shared fairly and nobody has to be reachable permanently.",[16,1969,1970],{},"The escalation chain governs what happens when the primary doesn't respond: primary → secondary → manager. If the first level doesn't react within a set deadline, the alert automatically moves to the next. This way no critical alert is left lying around just because someone happens not to pick up the phone.",[16,1972,1973,1974,1920],{},"The biggest enemy of a working on-call setup is alert fatigue. When too many or too imprecise alerts arrive, the on-call responders go numb and eventually miss the one alert that matters. Good alert thresholds, bundling related signals and protection against false alarms are therefore not niceties but a prerequisite for reliability. Which monitoring strategies reduce false alarms is described in the ",[20,1975,23],{"href":22},[11,1977,1979],{"id":1978},"incident-communication-internal-and-external","Incident Communication: Internal and External",[16,1981,1982],{},"Communication determines how an incident is perceived — often more strongly than the technical severity itself. There are two levels to separate here.",[16,1984,1985,1988],{},[26,1986,1987],{},"Internally",", it's about coordination: who is working on what, which hypothesis is currently being tested, which stakeholders need to know? This communication is allowed to be technical and detailed.",[16,1990,1991,1994],{},[26,1992,1993],{},"Externally",", toward customers, a different rule applies: speak the language of users, not of engineers. Nobody outside the team cares about the exact stack trace. Customers want to know: what isn't working, does it affect me, and when will I hear from you again?",[16,1996,1997],{},"A good external update contains four things:",[39,1999,2000,2006,2012,2018],{},[42,2001,2002,2005],{},[26,2003,2004],{},"Impact:"," what is concretely limited, in words users understand.",[42,2007,2008,2011],{},[26,2009,2010],{},"Affected services:"," which parts of the offering are touched, which run normally.",[42,2013,2014,2017],{},[26,2015,2016],{},"Current status:"," what you are doing right now, without false promises.",[42,2019,2020,2023],{},[26,2021,2022],{},"Next update time:"," when the next message will come — even if there's nothing new by then.",[16,2025,2026,2027,2030,2031,1280],{},"On cadence: better to update regularly, even without new findings, than to go silent. A \"we're still investigating, next update in 30 minutes\" signals that someone is on it. Silence reads as loss of control. Your own status page is the right channel for this, because it takes the load off support and offers a single reliable source — the fundamentals are explained in the ",[20,2028,2029],{"href":868},"what is a status page"," guide. How to shape tone and update rhythm in concrete terms is covered further in the ",[20,2032,1919],{"href":1918},[11,2034,2036],{"id":2035},"post-mortem-and-blameless-retrospective","Post-Mortem and Blameless Retrospective",[16,2038,2039],{},"The post-mortem is the step that turns an event into genuine learning. Without it, a team keeps fixing the same class of disruption over and over without ever finding the lever. A useful post-mortem is structured and records at least four components:",[39,2041,2042,2048,2053,2059],{},[42,2043,2044,2047],{},[26,2045,2046],{},"Timeline:"," what happened when, from detection to restoration. This is where the scribe's log pays off.",[42,2049,2050,2052],{},[26,2051,2004],{}," who was affected, for how long and how severely — number of users, duration, affected functions.",[42,2054,2055,2058],{},[26,2056,2057],{},"Root cause:"," the actual cause, not just the surface symptom.",[42,2060,2061,2064],{},[26,2062,2063],{},"Action items:"," concrete measures, each with an owner and a due date. A post-mortem without named owners and deadlines is a wish list, not an improvement.",[16,2066,2067],{},"What matters is the blameless attitude. \"Blameless\" means the focus is on system and process failures, not on assigning blame to individuals. The assumption is that people acted reasonably with the knowledge available to them — if something still went wrong, the system was fragile. A blameless culture encourages open analysis: only those who fear no punishment will honestly tell what really happened. That honesty is exactly what you need to find the true cause.",[16,2069,2070],{},"In practice: schedule the post-mortem promptly, typically within a few days of a major incident, while the details are still fresh.",[11,2072,2074],{"id":2073},"metrics-mtta-mttr-and-mtbf","Metrics: MTTA, MTTR and MTBF",[16,2076,2077],{},"Metrics make the quality of incident management measurable and show over time whether improvements are working. Three are central:",[39,2079,2080,2086,2092],{},[42,2081,2082,2085],{},[26,2083,2084],{},"MTTA (Mean Time To Acknowledge):"," the average time from a triggered alert to its acknowledgment, that is, until someone begins handling it. A high MTTA points to gaps in on-call or to alert fatigue.",[42,2087,2088,2091],{},[26,2089,2090],{},"MTTR (Mean Time To Recovery \u002F Repair \u002F Resolve):"," the average time from detection to restoration of the service. Probably the most-cited incident metric — it measures how quickly you are back online.",[42,2093,2094,2097],{},[26,2095,2096],{},"MTBF (Mean Time Between Failures):"," total operating time divided by the number of failures. Here a higher value is better, because it means longer stretches of disruption-free operation.",[16,2099,2100,2101,1920],{},"MTTA and MTTR target response and repair, MTBF targets fundamental stability. Together they give an honest picture: how reliable is the service, and how well does the team respond when something does happen. How these metrics relate to plain availability in percent is shown in the ",[20,2102,2104],{"href":2103},"\u002Fen\u002Fguides\u002Fuptime-percentage-explained","uptime percentage explained",[11,2106,2108],{"id":2107},"from-monitoring-alert-to-incident","From Monitoring Alert to Incident",[16,2110,2111],{},"In many setups there is an invisible gap between the monitoring alert and the public incident. Monitoring fires, someone sees the alert — and then has to manually open a separate incident or status page tool, create an event and type out the text. This context switch costs time, exactly when time is scarcest.",[16,2113,2114,2115,2117,2118,2120],{},"The effect is measurable: every manual handoff step lengthens MTTA and MTTR. It also creates friction — under stress, the status page update is easily forgotten or posted too late, because it's an extra, deliberate action. Specialized incident tools like ",[20,2116,1092],{"href":1376}," or ",[20,2119,1109],{"href":1387}," handle coordination and escalation well, but bring no monitoring of their own. So you still need a separate monitoring tool and have to connect both worlds. The closer detection and incident workflow sit together, the smaller this gap becomes.",[11,2122,2124],{"id":2123},"incident-management-with-livck","Incident Management with LIVCK",[16,2126,2127],{},"LIVCK is designed as one solution that unites monitoring and status page in a single tool — and thereby avoids exactly the context switch described above. The detected outage and the public incident live in the same system, instead of being manually reconciled across two tools.",[16,2129,2130,2131,2134,2135,2138,2139,2142,2143,2145],{},"For the actual incident handling, LIVCK offers a status workflow that follows the established scheme from Investigating through Identified and Monitoring to Resolved. ",[26,2132,2133],{},"Outage Linking"," groups several affected services with a shared cause into ",[34,2136,2137],{},"one"," incident — customers don't see five confusing separate notices, but one clear event. Alongside incidents, ",[26,2140,2141],{},"Announcements"," are available for general notices and ",[26,2144,1914],{}," for scheduled maintenance windows, so planned work stays cleanly separated from real disruptions.",[16,2147,2148,2149,2154,2155,1280],{},"Communication runs automatically: subscribers are notified across all relevant channels — email, Slack, Microsoft Teams, Telegram, Discord and webhooks. Against false alarms, majority detection protects you: an incident is only triggered after multiple independent probe locations have confirmed the disruption, which noticeably dampens alert fatigue in on-call. Escalation policies with acknowledge and postmortems attached directly to the incident round out the workflow. If you prefer self-hosting, you can install LIVCK in minutes via ",[20,2150,2153],{"href":2151,"rel":2152},"https:\u002F\u002Fhelp.livck.com",[759],"Docker Compose","; an overview of the status page features is available at ",[20,2156,2158],{"href":1292,"rel":2157},[759],"livck.cloud",[11,2160,2162],{"id":2161},"common-mistakes","Common Mistakes",[16,2164,2165],{},"A few patterns keep recurring and cost time and nerves in every incident anew:",[39,2167,2168,2174,2180,2186,2192,2198],{},[42,2169,2170,2173],{},[26,2171,2172],{},"No defined incident commander."," Without a clear owner, everyone talks over each other and nobody makes decisions.",[42,2175,2176,2179],{},[26,2177,2178],{},"No severity definition."," When it's unclear what separates a SEV1 from a SEV3, the team either over- or under-reacts.",[42,2181,2182,2185],{},[26,2183,2184],{},"Customer communication too late or too rare."," Going silent during an outage damages trust more than the outage itself.",[42,2187,2188,2191],{},[26,2189,2190],{},"Post-mortem with blame."," As soon as blame is in the room, the honest answers go quiet — and with them the chance to find the true cause.",[42,2193,2194,2197],{},[26,2195,2196],{},"Alert fatigue."," Too many imprecise alerts cause the one important one to be missed.",[42,2199,2200,2203],{},[26,2201,2202],{},"Separate, uncoupled tools."," Monitoring and incident communication in two worlds create a context switch that lengthens MTTA and MTTR.",[11,2205,772],{"id":771},[16,2207,2208],{},"Incident management is not a tool you buy, but a process you practice. The building blocks are manageable: a clear lifecycle from detection to post-mortem, defined severity levels, named roles with an incident commander at the top, a reliable on-call with an escalation chain, and honest, regular communication in the language of users. Metrics like MTTA, MTTR and MTBF make it visible whether the work is having an effect, and a blameless post-mortem turns every event into learning rather than blame.",[16,2210,2211],{},"The biggest lever often sits where detection and response meet: the shorter the path from monitoring alert to public incident, the faster you are able to act again and the calmer you can communicate. Bringing monitoring and status page together in one system closes exactly this gap — and wins you, in a real emergency, the minutes that count.",{"title":107,"searchDepth":121,"depth":121,"links":2213},[2214,2217,2224,2225,2226,2227,2228,2229,2230,2231,2232,2233],{"id":1680,"depth":121,"text":1681,"children":2215},[2216],{"id":1693,"depth":331,"text":1694},{"id":1723,"depth":121,"text":1724,"children":2218},[2219,2220,2221,2222,2223],{"id":1730,"depth":331,"text":1731},{"id":1740,"depth":331,"text":1741},{"id":1747,"depth":331,"text":1748},{"id":1754,"depth":331,"text":1755},{"id":1769,"depth":331,"text":1770},{"id":1776,"depth":121,"text":1777},{"id":1923,"depth":121,"text":1924},{"id":1963,"depth":121,"text":1964},{"id":1978,"depth":121,"text":1979},{"id":2035,"depth":121,"text":2036},{"id":2073,"depth":121,"text":2074},{"id":2107,"depth":121,"text":2108},{"id":2123,"depth":121,"text":2124},{"id":2161,"depth":121,"text":2162},{"id":771,"depth":121,"text":772},"Incident management explained: lifecycle, severity levels, roles, escalation, post-mortems and metrics like MTTR — plus professional incident communication.",{},"\u002Fguides\u002Fen\u002Fincident-management",13,[2239,2240,1665],"incident-io","ilert",[2242,848,1669],"statuspage-best-practices",{"title":1675,"description":2234},"guides\u002Fen\u002Fincident-management","2VH4r4fYEBtfLqksrXKwlX3QY11OJkxxm7sMfUK4qy0",{"id":2247,"title":2248,"body":2249,"category":834,"description":2832,"extension":836,"faq":837,"meta":2833,"navigation":334,"path":2834,"peerSlug":848,"publishedAt":1662,"readingTime":2237,"relatedComparisons":2835,"relatedGuides":2837,"seo":2839,"stem":2840,"updatedAt":837,"__hash__":2841},"guides\u002Fguides\u002Fen\u002Fuptime-monitoring.md","Uptime Monitoring: Fundamentals, Check Types and Choosing the Right Tool",{"type":8,"value":2250,"toc":2810},[2251,2255,2258,2261,2264,2278,2282,2285,2292,2296,2299,2302,2322,2328,2332,2335,2339,2342,2375,2379,2382,2386,2389,2393,2396,2400,2403,2407,2410,2413,2417,2420,2514,2518,2521,2524,2544,2547,2550,2554,2557,2577,2580,2585,2589,2592,2595,2601,2605,2608,2652,2662,2666,2687,2694,2697,2704,2730,2758,2762,2765,2791,2794,2796,2799,2808],[11,2252,2254],{"id":2253},"what-is-uptime-monitoring","What Is Uptime Monitoring?",[16,2256,2257],{},"Uptime monitoring is the continuous observation of a system's reachability from the outside. A monitoring service checks at fixed intervals whether your website, your API or your server responds — and whether the response is correct. That is the whole point of availability monitoring: not just \"is the server running\", but \"can a user actually reach and use the system\".",[16,2259,2260],{},"Technically, uptime monitoring is a black-box, or outside-in, form of observation. The monitoring system has no access to your source code or internal metrics. It looks at your system from the outside, exactly the way a real visitor would — over the network, with a request, evaluating the response. That is also its greatest strength: you measure precisely what your users experience, not just what an internal health check claims.",[16,2262,2263],{},"In website monitoring and server monitoring, two basic modes of operation complement each other:",[39,2265,2266,2272],{},[42,2267,2268,2271],{},[26,2269,2270],{},"Pull monitoring:"," The monitoring system actively queries the target. It sends an HTTP request, opens a TCP connection or sends a ping and evaluates the response. This is the standard case for publicly reachable services.",[42,2273,2274,2277],{},[26,2275,2276],{},"Push monitoring (heartbeat):"," The monitored system actively reports in to the monitoring service. If the expected signal fails to arrive, an alert fires. This suits cron jobs, background processes and systems behind a firewall that cannot be reached directly from the outside.",[65,2279,2281],{"id":2280},"difference-from-apm-and-performance-monitoring","Difference From APM and Performance Monitoring",[16,2283,2284],{},"Uptime monitoring is often confused with Application Performance Monitoring (APM), yet the two answer different questions. APM is white-box observation: it measures internal metrics such as database query times, error rates and code traces, and needs instrumentation directly in the application code.",[16,2286,2287,2288,2291],{},"The decisive difference can be put simply: ",[26,2289,2290],{},"Uptime monitoring tells you THAT something is broken. APM tells you WHY."," Uptime monitoring detects that the checkout page returns a 500. APM shows you that behind it sits a timeout to the payment database. The two complement each other, and neither replaces the other. For most websites, APIs and servers, solid uptime monitoring is the mandatory baseline — it is cheap, quick to set up and covers the most important question: is the system available to my users right now?",[11,2293,2295],{"id":2294},"why-monitoring-is-business-critical","Why Monitoring Is Business-Critical",[16,2297,2298],{},"The core principle: you learn about an outage first — not your customer. Without monitoring, the first report of an outage is often an annoyed user, a tweet or a support ticket. By that point the outage has already been running for a while, and you have lost control of the communication.",[16,2300,2301],{},"In practice, the cost of downtime falls into three areas:",[39,2303,2304,2310,2316],{},[42,2305,2306,2309],{},[26,2307,2308],{},"Revenue:"," Every outage in the ordering, booking or payment flow costs money directly. A shop that is unreachable for an hour loses not only that hour's orders, but often customers who never come back.",[42,2311,2312,2315],{},[26,2313,2314],{},"Trust and reputation:"," Repeated or uncommunicated outages damage trust — especially with B2B customers who depend on your service. Those who communicate transparently about incidents lose far less trust than those who stay silent.",[42,2317,2318,2321],{},[26,2319,2320],{},"SEO:"," Longer or frequent outages can affect crawling. If the search engine crawler repeatedly finds a page unreachable, that can affect indexing and ranking over the medium term.",[16,2323,2324,2325,1280],{},"What an hour of downtime actually costs depends heavily on the business model and cannot be stated as a blanket figure. An honest estimate works if you take your average revenue per hour and add the indirect costs — support effort, reputational damage, lost new customers. Even this simple calculation usually shows quickly that a monitoring tool for a few euros a month is cheap insurance. How much downtime different availability targets even permit is something we work through in detail in the guide ",[20,2326,2327],{"href":2103},"Uptime percentage explained",[11,2329,2331],{"id":2330},"the-most-important-check-types-in-detail","The Most Important Check Types in Detail",[16,2333,2334],{},"Not all uptime monitoring is the same. Depending on what you are monitoring, you need different check types. Anyone who only checks the home page over HTTP overlooks a whole range of failure scenarios.",[65,2336,2338],{"id":2337},"https-check","HTTP(S) Check",[16,2340,2341],{},"The HTTP(S) check is the most common type, and it does more than just verify that a page is reachable. It additionally evaluates:",[39,2343,2344,2366],{},[42,2345,2346,2349,2350,2353,2354,2357,2358,2361,2362,2365],{},[26,2347,2348],{},"The status code:"," A ",[82,2351,2352],{},"200 OK"," is good; a ",[82,2355,2356],{},"4xx"," (client error) or ",[82,2359,2360],{},"5xx"," (server error) signals a problem. A ",[82,2363,2364],{},"503 Service Unavailable"," is a classic outage signal.",[42,2367,2368,2371,2372,2374],{},[26,2369,2370],{},"Optionally a keyword or content in the body:"," This matters more than it sounds. A broken page can incorrectly return a ",[82,2373,2352],{}," and still show only a blank page or an error message. A content check looks for an expected term (for example \"Add to cart\") and raises an alert if it is missing — even when the status code is fine.",[65,2376,2378],{"id":2377},"tcpport-check","TCP\u002FPort Check",[16,2380,2381],{},"A TCP\u002Fport check verifies whether a specific port is open and accepting connections. This is relevant for services that do not run over HTTP: a database on port 5432 (PostgreSQL), a mail server on port 25 (SMTP) or any other network-based service. The check tells you whether the service accepts connections at all.",[65,2383,2385],{"id":2384},"icmpping-check","ICMP\u002FPing Check",[16,2387,2388],{},"An ICMP, or ping, check verifies the basic network reachability of a host. It tells you whether the server responds on the network — but not whether the services running on it work. A server can answer a ping while the web server has long since crashed. Ping is therefore a good first indicator, but no full substitute for a service-level check.",[65,2390,2392],{"id":2391},"ssl-certificate-check","SSL Certificate Check",[16,2394,2395],{},"Expired TLS certificates are one of the most common avoidable causes of outages. An SSL certificate check warns in good time before expiry — typically a few days ahead. That leaves enough time to renew the certificate before visitors see a security warning in their browser.",[65,2397,2399],{"id":2398},"dns-check","DNS Check",[16,2401,2402],{},"A DNS check verifies correct name resolution. If DNS fails or is misconfigured, your application is unreachable even though the server runs perfectly. DNS problems are insidious because they often surface only after configuration changes.",[65,2404,2406],{"id":2405},"heartbeatcron-monitoring","Heartbeat\u002FCron Monitoring",[16,2408,2409],{},"Heartbeat monitoring covers things that are neither an open port nor a URL: cron jobs, backup scripts, queue workers and other background processes. The principle is the reverse of pull monitoring: after a successful run, the job sends a ping to a URL. If the expected ping fails to arrive within the defined time window, the job is treated as failed and an alert fires.",[16,2411,2412],{},"This solves a problem that HTTP checks cannot address: a nightly backup script has no port you could check from the outside. If it does not complete, without a heartbeat nobody notices — until the backup is needed and missing.",[65,2414,2416],{"id":2415},"apimanual-check","API\u002FManual Check",[16,2418,2419],{},"Some states are known only to your own application. With an API, or manual, check you can set a status programmatically — for example to reflect a business-logic state that a generic check cannot detect.",[204,2421,2422,2435],{},[207,2423,2424],{},[210,2425,2426,2429,2432],{},[213,2427,2428],{},"Check type",[213,2430,2431],{},"Checks",[213,2433,2434],{},"Typical use",[220,2436,2437,2448,2459,2470,2481,2492,2503],{},[210,2438,2439,2442,2445],{},[225,2440,2441],{},"HTTP(S)",[225,2443,2444],{},"Status code + content",[225,2446,2447],{},"Websites, APIs",[210,2449,2450,2453,2456],{},[225,2451,2452],{},"TCP\u002FPort",[225,2454,2455],{},"Open port, connection",[225,2457,2458],{},"Databases, mail servers",[210,2460,2461,2464,2467],{},[225,2462,2463],{},"ICMP\u002FPing",[225,2465,2466],{},"Network reachability",[225,2468,2469],{},"Basic server check",[210,2471,2472,2475,2478],{},[225,2473,2474],{},"SSL",[225,2476,2477],{},"Certificate expiry",[225,2479,2480],{},"HTTPS services",[210,2482,2483,2486,2489],{},[225,2484,2485],{},"DNS",[225,2487,2488],{},"Name resolution",[225,2490,2491],{},"Domain configuration",[210,2493,2494,2497,2500],{},[225,2495,2496],{},"Heartbeat",[225,2498,2499],{},"Missing signal",[225,2501,2502],{},"Cron jobs, backups, workers",[210,2504,2505,2508,2511],{},[225,2506,2507],{},"Manual\u002FAPI",[225,2509,2510],{},"Custom status via API",[225,2512,2513],{},"Business logic",[11,2515,2517],{"id":2516},"check-interval-and-check-locations","Check Interval and Check Locations",[16,2519,2520],{},"The check interval determines how quickly you learn about an outage. With a 5-minute interval, an outage can go undetected for up to five minutes before the next check registers it. For many production systems that is too long.",[16,2522,2523],{},"As a rule of thumb:",[39,2525,2526,2532,2538],{},[42,2527,2528,2531],{},[26,2529,2530],{},"1 minute"," is the standard for production systems. A good compromise between fast detection and acceptable load.",[42,2533,2534,2537],{},[26,2535,2536],{},"30 seconds"," makes sense for critical systems where every minute counts — such as payment infrastructure or central APIs.",[42,2539,2540,2543],{},[26,2541,2542],{},"5 minutes or more"," is enough for non-critical secondary systems where short outages cause no harm.",[16,2545,2546],{},"A second, often underestimated factor is checking from multiple locations. If a target is checked from a single location only, a local network problem between the check point and the target can look like an outage — even though your application runs perfectly for everyone else. Multi-location monitoring checks from several geographic points and compares the results.",[16,2548,2549],{},"This is also where false-alarm protection comes in. Before an alert fires, the system should confirm a suspected failure: several check points must see the error (multi-location confirmation) and\u002For it is rechecked after a short delay (retry\u002Fconfirmation). Many transient glitches resolve themselves within 5 to 10 seconds — a brief recheck prevents them from turning into an alert.",[11,2551,2553],{"id":2552},"alerting-and-escalation","Alerting and Escalation",[16,2555,2556],{},"Monitoring that detects an outage but reaches no one is worthless. Alerting is therefore just as important as the check itself. In practice you need several channels, because different situations demand different levels of attention:",[39,2558,2559,2565,2571],{},[42,2560,2561,2564],{},[26,2562,2563],{},"Email"," for documentation and non-urgent notices.",[42,2566,2567,2570],{},[26,2568,2569],{},"Slack, Discord or Telegram"," for quick information in team chat.",[42,2572,2573,2576],{},[26,2574,2575],{},"SMS or Pushover"," for critical alerts that must arrive even at night.",[16,2578,2579],{},"The most important and most frequently underestimated aspect is alert fatigue. Anyone who receives too many or constantly repeated alerts becomes desensitized — and eventually misses the one alert that really matters. The remedies are throttling (not reporting every repetition again), grouping related alerts and clearly defined escalation paths: who is informed first, who takes over if no one responds?",[16,2581,2582,2583,1920],{},"This is exactly where monitoring becomes a process. Anyone working with on-call rotations needs clear rules for when an alert escalates and to whom. How you get from the first notification to a structured response is something we cover in detail in the ",[20,2584,899],{"href":748},[11,2586,2588],{"id":2587},"monitoring-and-statuspage-belong-together","Monitoring and Statuspage Belong Together",[16,2590,2591],{},"An alert informs your team. But what about your users? When an outage is confirmed, customers want to know what is going on — without having to open a support ticket first. This is exactly where the loop between monitoring and statuspage closes.",[16,2593,2594],{},"Ideally, a confirmed outage leads not only to an internal alert, but can be turned directly into a public statuspage update: a service is set to \"degraded\", subscribers are notified automatically, and your team can communicate the incident transparently while working on the fix. That takes pressure off support and builds trust.",[16,2596,2597,2598,1280],{},"For this to work, monitoring and statuspage should not be two separate tools that you sync manually. What matters in a good statuspage — from service structure to incident communication — is something we have summarized in the ",[20,2599,2600],{"href":1918},"Statuspage best practices",[11,2602,2604],{"id":2603},"criteria-for-choosing-a-tool","Criteria for Choosing a Tool",[16,2606,2607],{},"Which monitoring tool is the right one depends on your requirements. The following criteria help you compare offerings on the merits, rather than being dazzled by feature lists:",[39,2609,2610,2616,2622,2628,2634,2640,2646],{},[42,2611,2612,2615],{},[26,2613,2614],{},"Check types:"," Does the tool cover what you actually monitor? Plain HTTP is rarely enough — TCP, SSL and heartbeat belong in most setups.",[42,2617,2618,2621],{},[26,2619,2620],{},"Check interval:"," Does the plan you need offer an interval that is fast enough? Some cheap tiers are capped at 5 minutes.",[42,2623,2624,2627],{},[26,2625,2626],{},"Multi-location:"," Does it check from several locations to avoid false alarms?",[42,2629,2630,2633],{},[26,2631,2632],{},"Self-hosting option:"," Can you run the monitoring on your own infrastructure when you need full control?",[42,2635,2636,2639],{},[26,2637,2638],{},"Data privacy and server location:"," Where is the data processed? For companies with customers in the EU, a European or German server location is often mandatory.",[42,2641,2642,2645],{},[26,2643,2644],{},"Free tier:"," Is there a free entry point that lets you test the tool for real?",[42,2647,2648,2651],{},[26,2649,2650],{},"Incident integration:"," Can an alert be turned directly into statuspage communication, or does monitoring stay an isolated silo?",[16,2653,2654,2655,564,2657,738,2659,2661],{},"If you want to weigh specific providers against each other, you will find detailed comparisons — for example for ",[20,2656,690],{"href":721},[20,2658,701],{"href":1320},[20,2660,1161],{"href":1425},". There you can see in detail where each one's strengths and limits lie, particularly when it comes to server location and the link between monitoring and statuspage.",[11,2663,2665],{"id":2664},"uptime-monitoring-with-livck","Uptime Monitoring With LIVCK",[16,2667,2668,2669,564,2671,564,2673,564,2676,564,2678,564,2680,2682,2683,2686],{},"LIVCK combines uptime monitoring and statuspage in a single tool — that is the essential difference from solutions that only monitor or only provide a statuspage. For monitoring, seven check types are available: ",[26,2670,2441],{},[26,2672,2452],{},[26,2674,2675],{},"Ping",[26,2677,2485],{},[26,2679,2474],{},[26,2681,2496],{}," (for cron jobs and background processes) and ",[26,2684,2685],{},"Manual"," via the API. This covers publicly reachable services, certificate expiry, DNS configuration and jobs behind a firewall.",[16,2688,2689,2690,2693],{},"Against false alarms, LIVCK works with ",[26,2691,2692],{},"majority detection across independent probe locations",": an incident is only triggered once the majority of locations confirm the error — checks run from up to eight locations, six of them in the DACH region. Transient glitches that resolve themselves after a few seconds therefore do not lead to unnecessary alerts and alert fatigue. Notifications run over email, SMS, voice call, Slack, Microsoft Teams, Telegram, Discord and webhooks.",[16,2695,2696],{},"The decisive advantage is the direct statuspage integration: a confirmed outage becomes a public update with automatic subscriber notification, without switching tools. Statuspage features such as custom branding, private pages and the uptime calendar are included in every plan, at no extra cost.",[16,2698,2699,2700,2703],{},"For operation, you have a choice. ",[26,2701,2702],{},"Self-hosted via Docker Compose"," is set up in minutes:",[102,2705,2706],{"className":104,"code":1236,"language":106,"meta":107,"style":107},[82,2707,2708,2720],{"__ignoreMap":107},[111,2709,2710,2712,2714,2716,2718],{"class":113,"line":114},[111,2711,84],{"class":124},[111,2713,1245],{"class":128},[111,2715,1248],{"class":139},[111,2717,164],{"class":128},[111,2719,1253],{"class":139},[111,2721,2722,2724,2726,2728],{"class":113,"line":121},[111,2723,1258],{"class":124},[111,2725,1261],{"class":139},[111,2727,1264],{"class":139},[111,2729,1267],{"class":128},[16,2731,2732,2733,2737,2738,2741,2742,2745,2746,1289,2749,2753,2754,2757],{},"A modest entry-level server is already enough, such as the ",[20,2734,2736],{"href":757,"rel":2735},[759],"Hetzner Cloud CX22 from about €4.75\u002Fmonth"," — the only important point is that the monitoring does not run on the same infrastructure as the systems it monitors. Alternatively, a ",[26,2739,2740],{},"managed service on German servers"," is available, and the ",[26,2743,2744],{},"LIVCK Cloud Free plan"," (€0, 20 services, 120s interval, 1 statuspage) is in public beta — access via the waitlist. Because LIVCK comes from Germany and works GDPR by design, it is particularly well suited to regulated industries. You can find more on scope and installation in the ",[20,2747,1288],{"href":1286,"rel":2748},[759],[20,2750,2752],{"href":1292,"rel":2751},[759],"statuspage overview",". If you are generally interested in running things yourself, the guide on the ",[20,2755,2756],{"href":1278},"self-hosted statuspage"," is worth a look too.",[11,2759,2761],{"id":2760},"common-monitoring-mistakes","Common Monitoring Mistakes",[16,2763,2764],{},"Even with the right tool, there are typical mistakes that undermine monitoring:",[39,2766,2767,2773,2779,2785],{},[42,2768,2769,2772],{},[26,2770,2771],{},"Only checking the home page:"," The home page can run perfectly while login, checkout or API have failed. Monitor the business-critical paths, not just the shop window.",[42,2774,2775,2778],{},[26,2776,2777],{},"Intervals that are too long:"," A 15-minute interval may save a few cents, but it leaves an outage undetected for a quarter of an hour. For critical systems that is too slow.",[42,2780,2781,2784],{},[26,2782,2783],{},"Monitoring on the same infrastructure:"," If monitoring runs on the same server or in the same data center as the monitored systems, it fails together with them — exactly when you need it most. Monitoring always belongs on independent infrastructure.",[42,2786,2787,2790],{},[26,2788,2789],{},"No alerting escalation path:"," An alert that only lands in an ignored email inbox helps no one. Define who is notified when, and what happens if no one responds.",[16,2792,2793],{},"These four points cost nothing but a little attention during setup — and in practice they decide whether your monitoring holds up when it matters or not.",[11,2795,772],{"id":771},[16,2797,2798],{},"Uptime monitoring is the cheapest insurance you can take out for your digital services: you learn about an outage before your customers do. What matters is that the monitoring fits what you run — with the right check types (not just HTTP, but also TCP, SSL and heartbeat for cron jobs), a sufficiently short check interval, false-alarm protection through multiple confirmation and a well-thought-out alerting path.",[16,2800,2801,2802,2804,2805,1280],{},"You get the most out of it when monitoring and statuspage do not sit in separate silos but work together: a confirmed outage turns directly into transparent communication to your users. How quickly you need to react depends on your availability target — you will find the concrete numbers in the guide ",[20,2803,2327],{"href":2103},". Finally, make sure to run the monitoring on independent infrastructure and — if data privacy matters to you — to check server location and ",[20,2806,2807],{"href":1516},"GDPR compliance",[812,2809,1608],{},{"title":107,"searchDepth":121,"depth":121,"links":2811},[2812,2815,2816,2825,2826,2827,2828,2829,2830,2831],{"id":2253,"depth":121,"text":2254,"children":2813},[2814],{"id":2280,"depth":331,"text":2281},{"id":2294,"depth":121,"text":2295},{"id":2330,"depth":121,"text":2331,"children":2817},[2818,2819,2820,2821,2822,2823,2824],{"id":2337,"depth":331,"text":2338},{"id":2377,"depth":331,"text":2378},{"id":2384,"depth":331,"text":2385},{"id":2391,"depth":331,"text":2392},{"id":2398,"depth":331,"text":2399},{"id":2405,"depth":331,"text":2406},{"id":2415,"depth":331,"text":2416},{"id":2516,"depth":121,"text":2517},{"id":2552,"depth":121,"text":2553},{"id":2587,"depth":121,"text":2588},{"id":2603,"depth":121,"text":2604},{"id":2664,"depth":121,"text":2665},{"id":2760,"depth":121,"text":2761},{"id":771,"depth":121,"text":772},"Uptime monitoring explained: check types (HTTP, TCP, heartbeat), intervals, alerting and how to choose a tool — including self-hosting and GDPR.",{},"\u002Fguides\u002Fen\u002Fuptime-monitoring",[846,1666,2836],"hetrixtools",[2838,849,2242],"uptime-percentage-explained",{"title":2248,"description":2832},"guides\u002Fen\u002Fuptime-monitoring","QJCLMWfRd3cgXQdDpVJ1EpANeP0-nDxpFh2lgy1k3b0",{"id":2843,"title":2844,"body":2845,"category":2888,"description":3276,"extension":836,"faq":3277,"meta":3291,"navigation":334,"path":3292,"peerSlug":3293,"publishedAt":1662,"readingTime":3294,"relatedComparisons":3295,"relatedGuides":3296,"seo":3297,"stem":3298,"updatedAt":837,"__hash__":3299},"guides\u002Fguides\u002Fen\u002Fuptime-percentage-explained.md","Uptime Percentage Explained: What Does 99.9% Really Mean?",{"type":8,"value":2846,"toc":3261},[2847,2851,2854,2857,2862,2865,2870,2873,2877,2880,3005,3008,3012,3015,3071,3074,3078,3081,3084,3105,3108,3115,3119,3122,3142,3157,3161,3164,3168,3171,3174,3177,3181,3184,3212,3218,3222,3225,3229,3232,3238,3243,3247,3256,3258],[11,2848,2850],{"id":2849},"what-does-availability-uptime-mean","What Does Availability (Uptime) Mean?",[16,2852,2853],{},"Availability — often used interchangeably with uptime — is the share of time during which a system is reachable and working as intended, expressed as a percentage over a defined period. A website with 99.9% availability in a month was therefore unavailable for roughly 0.1% of that month.",[16,2855,2856],{},"The calculation follows a simple formula:",[16,2858,2859],{},[26,2860,2861],{},"Availability (%) = (Total Time − Downtime) \u002F Total Time × 100",[16,2863,2864],{},"If you want to work backwards from availability to the permitted downtime, flip the formula around:",[16,2866,2867],{},[26,2868,2869],{},"Downtime = (1 − Availability) × Total Time",[16,2871,2872],{},"Every number in this guide rests on one consistent assumption: 365 days per year and 30 days per month. That is the common convention used for the downtime table below as well. If you calculate against different reference periods (business hours instead of 24\u002F7, for example), you get different values — which is why the reference period always belongs to the figure.",[11,2874,2876],{"id":2875},"the-downtime-table-99-to-99999-at-a-glance","The Downtime Table: 99% to 99.999% at a Glance",[16,2878,2879],{},"The percentage alone says little. Only the conversion into real downtime makes tangible what an availability level means in practice. The following table translates the common levels into maximum downtime per year, month, week and day (basis: 365 days\u002Fyear, 30 days\u002Fmonth).",[204,2881,2882,2901],{},[207,2883,2884],{},[210,2885,2886,2889,2892,2895,2898],{},[213,2887,2888],{},"Availability",[213,2890,2891],{},"Downtime \u002F Year",[213,2893,2894],{},"Downtime \u002F Month",[213,2896,2897],{},"Downtime \u002F Week",[213,2899,2900],{},"Downtime \u002F Day",[220,2902,2903,2920,2937,2954,2971,2988],{},[210,2904,2905,2908,2911,2914,2917],{},[225,2906,2907],{},"99%",[225,2909,2910],{},"3.65 days",[225,2912,2913],{},"7.2 hrs",[225,2915,2916],{},"1.68 hrs",[225,2918,2919],{},"14.4 min",[210,2921,2922,2925,2928,2931,2934],{},[225,2923,2924],{},"99.5%",[225,2926,2927],{},"1.83 days",[225,2929,2930],{},"3.6 hrs",[225,2932,2933],{},"50.4 min",[225,2935,2936],{},"7.2 min",[210,2938,2939,2942,2945,2948,2951],{},[225,2940,2941],{},"99.9%",[225,2943,2944],{},"8.76 hrs",[225,2946,2947],{},"43.2 min",[225,2949,2950],{},"10.1 min",[225,2952,2953],{},"1.44 min",[210,2955,2956,2959,2962,2965,2968],{},[225,2957,2958],{},"99.95%",[225,2960,2961],{},"4.38 hrs",[225,2963,2964],{},"21.6 min",[225,2966,2967],{},"5.04 min",[225,2969,2970],{},"43.2 sec",[210,2972,2973,2976,2979,2982,2985],{},[225,2974,2975],{},"99.99%",[225,2977,2978],{},"52.6 min",[225,2980,2981],{},"4.32 min",[225,2983,2984],{},"60.5 sec",[225,2986,2987],{},"8.64 sec",[210,2989,2990,2993,2996,2999,3002],{},[225,2991,2992],{},"99.999%",[225,2994,2995],{},"5.26 min",[225,2997,2998],{},"25.9 sec",[225,3000,3001],{},"6.05 sec",[225,3003,3004],{},"0.86 sec",[16,3006,3007],{},"The key takeaway: each additional nine cuts the permitted downtime by roughly a factor of 10. Going from 99% to 99.9% shrinks the yearly downtime from 3.65 days to 8.76 hours — and from there down to 52.6 minutes at 99.99%.",[11,3009,3011],{"id":3010},"the-nines-uptime-levels-explained","The \"Nines\": Uptime Levels Explained",[16,3013,3014],{},"In operations jargon, availability is often described by the number of nines. It is a shorthand that has caught on because it conveys the order of magnitude at a glance.",[204,3016,3017,3029],{},[207,3018,3019],{},[210,3020,3021,3024,3026],{},[213,3022,3023],{},"Level",[213,3025,2888],{},[213,3027,3028],{},"Name",[220,3030,3031,3041,3051,3061],{},[210,3032,3033,3036,3038],{},[225,3034,3035],{},"Two Nines",[225,3037,2907],{},[225,3039,3040],{},"two nines",[210,3042,3043,3046,3048],{},[225,3044,3045],{},"Three Nines",[225,3047,2941],{},[225,3049,3050],{},"three nines",[210,3052,3053,3056,3058],{},[225,3054,3055],{},"Four Nines",[225,3057,2975],{},[225,3059,3060],{},"four nines",[210,3062,3063,3066,3068],{},[225,3064,3065],{},"Five Nines",[225,3067,2992],{},[225,3069,3070],{},"five nines",[16,3072,3073],{},"\"Three nines\" means 99.9%, \"four nines\" 99.99%, \"five nines\" 99.999%. Five nines — about 5 minutes of downtime per year — is considered the gold standard for highly critical infrastructure such as telecommunications or payment processing. For most web services, three nines is a realistic and sensible target.",[11,3075,3077],{"id":3076},"what-does-999-mean-in-practice-a-worked-example","What Does 99.9% Mean in Practice? A Worked Example",[16,3079,3080],{},"99.9% sounds like \"almost never offline.\" Concretely, it means up to 43.2 minutes of downtime per month and 8.76 hours per year are baked into this level. That is more than many people intuitively assume.",[16,3082,3083],{},"The math behind it, step by step:",[73,3085,3086,3092,3099],{},[42,3087,3088,3089,1280],{},"A 30-day month has 30 × 24 × 60 = ",[26,3090,3091],{},"43,200 minutes",[42,3093,3094,3095,3098],{},"Suppose a service was unreachable for a total of ",[26,3096,3097],{},"43 minutes"," that month.",[42,3100,3101,3102,1280],{},"Plugged into the formula: (43,200 − 43) \u002F 43,200 × 100 ≈ ",[26,3103,3104],{},"99.90%",[16,3106,3107],{},"So 43 minutes of downtime in a month lands exactly on the 99.9% mark. A single longer incident — a failed deployment, an overloaded backend — can burn through that budget on its own.",[16,3109,3110,3111,3114],{},"The inversion is just as direct: anyone committing to 99.9% per month has a downtime budget of 0.001 × 43,200 = ",[26,3112,3113],{},"43.2 minutes",". Those 43.2 minutes are the ceiling you can move within without missing the commitment.",[11,3116,3118],{"id":3117},"sla-vs-slo-vs-sli-three-terms-cleanly-separated","SLA vs. SLO vs. SLI: Three Terms, Cleanly Separated",[16,3120,3121],{},"Three acronyms circulate around availability that are constantly confused. They describe different things and belong clearly apart.",[39,3123,3124,3130,3136],{},[42,3125,3126,3129],{},[26,3127,3128],{},"SLA (Service Level Agreement)"," — the contractual commitment toward customers. An SLA is binding and has consequences: if the promised availability is missed, a credit or penalty typically kicks in. Example: \"99.9% availability per calendar month, otherwise a 10% credit on the monthly fee.\"",[42,3131,3132,3135],{},[26,3133,3134],{},"SLO (Service Level Objective)"," — the internal target the operation steers by. It is usually stricter than the SLA and serves as a buffer. If you promise 99.9% externally, you might set yourself 99.95% as an SLO internally, so you are not operating right at the contractual edge.",[42,3137,3138,3141],{},[26,3139,3140],{},"SLI (Service Level Indicator)"," — the actually measured metric against which SLO and SLA are checked. An SLI is a concrete number, such as the success rate of reachable requests or the share of responses below a given latency. The SLI tells you where you really stand.",[16,3143,3144,3145,3148,3149,3152,3153,3156],{},"So the chain is: you ",[26,3146,3147],{},"measure"," the SLI, compare it against the ",[26,3150,3151],{},"target"," (SLO) and thereby (hopefully) meet the ",[26,3154,3155],{},"commitment"," (SLA).",[65,3158,3160],{"id":3159},"what-is-an-error-budget","What Is an Error Budget?",[16,3162,3163],{},"The error budget follows from the SLO — the remaining downtime the target permits within the period. With an SLO of 99.9% per month, the error budget is roughly 43.2 minutes. As long as less downtime occurs, there is headroom, for example for riskier deployments or migrations. Once the budget is exhausted, that is a clear signal to put stability ahead of new features. The error budget turns the abstract percentage into an operational steering metric.",[11,3165,3167],{"id":3166},"what-is-a-realistic-availability","What Is a Realistic Availability?",[16,3169,3170],{},"The obvious question is: why not simply 100%? The honest answer: 100% availability is unrealistic and is not seriously promised. Hardware fails, networks have outages, software needs updates, and no provider controls the entire chain down to the end user. Anyone promising 100% is ignoring that reality.",[16,3172,3173],{},"What is also decisive: effort and cost rise exponentially with each additional nine, while the benefit declines. The jump from 99.9% to 99.99% means pushing yearly downtime from nearly nine hours to under one hour — which requires redundancy, automatic failover, multiple availability zones and tight monitoring. The jump to 99.999% demands near-seamless automation of every recovery step, because there is simply no time left for manual intervention.",[16,3175,3176],{},"For most websites and SaaS services, 99.9% is a reasonable target with a good effort-to-benefit ratio. 99.99% pays off when outages directly cost revenue or trust. Five nines is the domain of infrastructure whose failure would have systemic consequences. The right level is a business decision, not a purely technical one.",[11,3178,3180],{"id":3179},"how-do-you-measure-uptime-correctly","How Do You Measure Uptime Correctly?",[16,3182,3183],{},"An availability figure is only as good as the method behind it. Two services both reporting \"99.95%\" can be far apart in reality if they were measured differently. These points belong defined before the first number:",[39,3185,3186,3194,3200,3206],{},[42,3187,3188,3191,3192,1280],{},[26,3189,3190],{},"Check interval."," How often is the check run? Too coarse an interval skews the measured uptime upward, because short outages between two checks go undetected. If you only check every five minutes, a two-minute blip is simply invisible. How tightly to check and which check types exist is covered in detail by the guide on ",[20,3193,23],{"href":22},[42,3195,3196,3199],{},[26,3197,3198],{},"What counts as downtime?"," Only a full outage, or also error responses (HTTP 500), responses that are too slow, or individual failed checks? This definition largely decides the number.",[42,3201,3202,3205],{},[26,3203,3204],{},"Planned maintenance."," Does an announced maintenance window count as downtime or not? In SLA definitions, planned maintenance is frequently excluded (maintenance windows). That is legitimate, but it must be set out transparently — otherwise two uptime figures are simply not comparable.",[42,3207,3208,3211],{},[26,3209,3210],{},"Measurement point."," Where is the check run from? From the same data center, from multiple regions, from the user's perspective? A single measurement point can mistake local network issues for a global outage, or conversely miss a real outage.",[16,3213,3214,3215,1280],{},"Only once these four points are clear is an availability figure trustworthy. Cleanly measured outages also become incidents you can analyze — how to handle and review them in a structured way is described by the guide on ",[20,3216,3217],{"href":748},"incident management",[11,3219,3221],{"id":3220},"does-planned-maintenance-count-as-downtime","Does Planned Maintenance Count as Downtime?",[16,3223,3224],{},"This question comes up so often that it deserves its own clear answer: it depends — and that is precisely why it must be defined. Technically, the service is unreachable during a maintenance window, so it would be downtime. Contractually, however, many SLAs deliberately exclude announced maintenance, because planned work is predictable and can be communicated. Both views are defensible. The only indefensible option is to leave the rule unstated and report different numbers depending on interpretation. If you exclude maintenance, you should disclose it openly — and announce the maintenance in advance instead of letting it run silently in the background.",[11,3226,3228],{"id":3227},"communicating-availability-transparently-with-livck","Communicating Availability Transparently — with LIVCK",[16,3230,3231],{},"Honestly measured availability only delivers its value when it is visible. That is exactly what a status page is for: it shows the current state, historical uptime and ongoing incidents in one place, instead of generating support tickets.",[16,3233,3234,3237],{},[20,3235,635],{"href":1292,"rel":3236},[759]," covers this chain from measurement to display — monitoring and status page in one tool, made in Germany. Checks run across several types: HTTP(S), TCP\u002Fport, ping, DNS, SSL, heartbeat (for cron jobs and background processes) and manual via API. Majority detection guards against false alarms: an incident is only triggered once multiple independent probe locations confirm the outage — keeping your uptime figures free of phantom outages caused by brief network hiccups.",[16,3239,3240,3241,1280],{},"On the status page itself, an uptime calendar and an SLA display present the calculated availability per service over time. Both are included in every plan — even the free Smart plan. Planned maintenance windows can be announced as maintenance, so visitors immediately tell the difference between scheduled work and a real outage. For more on designing a meaningful page, see the ",[20,3242,1919],{"href":1918},[11,3244,3246],{"id":3245},"availability-across-the-tools","Availability Across the Tools",[16,3248,3249,3250,3252,3253,3255],{},"Not every monitoring tool measures and communicates availability equally well. Pure monitoring services like ",[20,3251,690],{"href":721}," deliver check data but offer only a rudimentary status page. Pure status page providers like ",[20,3254,990],{"href":1308}," display states nicely but measure nothing themselves — you need a second tool for the actual checks. Anyone who wants to calculate availability cleanly and present it transparently benefits when measurement and display come from one source and work to the same definition.",[11,3257,772],{"id":771},[16,3259,3260],{},"Availability is a simple formula with surprisingly far-reaching consequences. 99.9% sounds close to perfect, yet it permits 43.2 minutes of downtime per month — and every further nine multiplies the effort of holding the budget tenfold. Anyone serious about uptime cleanly separates the measured metric (SLI), the internal target (SLO) and the contractual commitment (SLA), sets the check interval, downtime definition, treatment of maintenance and measurement point in advance, and communicates the numbers openly. 100% is not a realistic target — but an honestly measured and transparently shown 99.9% is. It is precisely that transparency, from measurement through the error budget to the uptime calendar on the status page, that builds the trust a bare percentage alone can never reach.",{"title":107,"searchDepth":121,"depth":121,"links":3262},[3263,3264,3265,3266,3267,3270,3271,3272,3273,3274,3275],{"id":2849,"depth":121,"text":2850},{"id":2875,"depth":121,"text":2876},{"id":3010,"depth":121,"text":3011},{"id":3076,"depth":121,"text":3077},{"id":3117,"depth":121,"text":3118,"children":3268},[3269],{"id":3159,"depth":331,"text":3160},{"id":3166,"depth":121,"text":3167},{"id":3179,"depth":121,"text":3180},{"id":3220,"depth":121,"text":3221},{"id":3227,"depth":121,"text":3228},{"id":3245,"depth":121,"text":3246},{"id":771,"depth":121,"text":772},"What does 99.9% uptime mean? Downtime table from 99% to 99.999%, the formula to calculate availability and the difference between SLA, SLO and SLI.",[3278,3280,3283,3285,3287,3289],{"question":2850,"answer":3279},"Availability — often used interchangeably with uptime — is the share of time during which a system is reachable and working as intended, expressed as a percentage over a defined period. It is calculated as (Total Time − Downtime) \u002F Total Time × 100; a website with 99.9% availability in a month was unavailable for roughly 0.1% of that month.",{"question":3281,"answer":3282},"What Does 99.9% Mean in Practice?","99.9% permits up to 43.2 minutes of downtime per month and 8.76 hours per year. A 30-day month has 43,200 minutes; 43 minutes of downtime yields (43,200 − 43) \u002F 43,200 × 100 ≈ 99.90%. The downtime budget is 0.001 × 43,200 = 43.2 minutes.",{"question":3160,"answer":3284},"The error budget is the remaining downtime the SLO permits within the period — with an SLO of 99.9% per month, roughly 43.2 minutes. As long as less downtime occurs, there is headroom for riskier deployments; once the budget is exhausted, it is a clear signal to put stability ahead of new features.",{"question":3167,"answer":3286},"100% availability is unrealistic and is not seriously promised. For most websites and SaaS services, 99.9% is a reasonable target; 99.99% pays off when outages directly cost revenue or trust, and five nines is the domain of critical infrastructure. The right level is a business decision, not a purely technical one.",{"question":3180,"answer":3288},"An availability figure is only as good as its measurement method. Four points must be defined in advance: the check interval (too coarse an interval skews uptime upward), what counts as downtime (only a full outage or also error responses and responses that are too slow), the treatment of planned maintenance, and the measurement point (from one or multiple regions).",{"question":3221,"answer":3290},"It depends — and that is precisely why it must be defined. Technically the service is unreachable during a maintenance window, yet many SLAs deliberately exclude announced maintenance contractually. If you exclude maintenance, you should disclose it openly and announce the maintenance in advance.",{},"\u002Fguides\u002Fen\u002Fuptime-percentage-explained","verfuegbarkeit-uptime-berechnen",10,[846,1665,1666],[848,849,2242],{"title":2844,"description":3276},"guides\u002Fen\u002Fuptime-percentage-explained","LvD6oYQsVA5osCyqou9Rjd8DbdL2j-oFqbbwrEMwmuk",{"id":3301,"title":3302,"body":3303,"category":3686,"description":3687,"extension":836,"faq":837,"meta":3688,"navigation":334,"path":3689,"peerSlug":3690,"publishedAt":3691,"readingTime":842,"relatedComparisons":3692,"relatedGuides":3693,"seo":3694,"stem":3695,"updatedAt":837,"__hash__":3696},"guides\u002Fguides\u002Fen\u002Fgdpr-statuspage.md","GDPR & Statuspage — Data Privacy, Cloud Act & European Alternatives",{"type":8,"value":3304,"toc":3650},[3305,3309,3312,3315,3318,3322,3325,3329,3332,3336,3339,3343,3346,3350,3353,3357,3360,3364,3367,3370,3373,3377,3380,3383,3387,3390,3393,3396,3400,3403,3407,3413,3419,3425,3431,3434,3438,3441,3445,3451,3457,3463,3469,3472,3476,3479,3483,3500,3504,3521,3525,3542,3546,3560,3564,3578,3582,3585,3589,3592,3596,3599,3603,3606,3610,3613,3617,3620,3623,3626,3629,3633,3636,3639,3641,3644,3647],[11,3306,3308],{"id":3307},"why-gdpr-matters-for-statuspages","Why GDPR matters for statuspages",[16,3310,3311],{},"A statuspage seems harmless at first glance. It publicly displays whether systems are operational. No login forms, no shopping carts, no payment data. But this impression is misleading.",[16,3313,3314],{},"The moment a statuspage manages subscribers, sends email notifications, collects monitoring data, or logs access requests, it processes personal data. And with that, the General Data Protection Regulation (GDPR) applies in full.",[16,3316,3317],{},"For organizations in regulated industries — data centers, financial services, healthcare, the public sector — choosing a statuspage provider is not a purely technical decision. It is a compliance decision.",[11,3319,3321],{"id":3320},"what-personal-data-a-statuspage-processes","What personal data a statuspage processes",[16,3323,3324],{},"Many operators underestimate the scope of data processing. A typical statuspage collects and stores the following categories of personal data:",[65,3326,3328],{"id":3327},"subscriber-data","Subscriber data",[16,3330,3331],{},"Anyone who signs up for status updates provides at least an email address. With differentiated notifications, preferences are added — which services are of interest, which channels are preferred (email, SMS, Slack, webhook). Each of these data points qualifies as personal data under the GDPR.",[65,3333,3335],{"id":3334},"monitoring-logs-and-access-records","Monitoring logs and access records",[16,3337,3338],{},"Monitoring systems log HTTP responses, TCP connections, heartbeat signals. These logs contain IP addresses, timestamps, and in some cases hostnames. Combined, they allow conclusions about infrastructure, usage patterns, and availability metrics.",[65,3340,3342],{"id":3341},"team-accounts-and-credentials","Team accounts and credentials",[16,3344,3345],{},"Internal users of the statuspage — DevOps teams, support staff, administrators — store names, email addresses, roles, and authentication data. Two-factor authentication generates additional metadata.",[65,3347,3349],{"id":3348},"incident-communication","Incident communication",[16,3351,3352],{},"Incident updates, postmortems, and maintenance announcements may contain names of contact persons. Subscriber notifications create delivery logs with recipient addresses and timestamps.",[65,3354,3356],{"id":3355},"web-analytics-data","Web analytics data",[16,3358,3359],{},"Even without traditional tracking, every web server records access logs: IP addresses, user agents, referrers, page views. Those who deploy Google Analytics or comparable tools significantly expand this dataset.",[11,3361,3363],{"id":3362},"the-us-cloud-act-a-structural-problem","The US Cloud Act — a structural problem",[16,3365,3366],{},"The Clarifying Lawful Overseas Use of Data Act (CLOUD Act) entered into force in the United States in 2018. It authorizes US authorities to compel US companies to hand over data — regardless of where that data is physically stored.",[16,3368,3369],{},"In practical terms, this means: even if a US provider operates its servers in Frankfurt, US authorities can demand access to the data stored there. The physical location of the data is irrelevant. What matters is the jurisdiction of the company that controls it.",[16,3371,3372],{},"For European organizations, this creates a fundamental conflict. The GDPR prohibits the transfer of personal data to third countries without an adequate level of protection. The Cloud Act obliges US companies to disclose precisely that data. Both laws apply simultaneously, and neither yields to the other.",[65,3374,3376],{"id":3375},"why-eu-region-at-us-providers-is-not-enough","Why \"EU region\" at US providers is not enough",[16,3378,3379],{},"Many US statuspage providers advertise European data centers or an \"EU region\" option. This sounds reassuring but does not solve the problem. The Cloud Act is not tied to the storage location but to control over the data. As long as a US company controls the data — as operator, parent company, or data processor — the Cloud Act applies.",[16,3381,3382],{},"A data center in Frankfurt, operated by a company headquartered in San Francisco, is not a European data center from a GDPR perspective.",[11,3384,3386],{"id":3385},"schrems-ii-and-its-consequences","Schrems II and its consequences",[16,3388,3389],{},"In July 2020, the Court of Justice of the European Union (CJEU) invalidated the EU-US Privacy Shield agreement in the landmark \"Schrems II\" ruling. The reasoning: the United States does not provide an adequate level of data protection within the meaning of the GDPR. In particular, US intelligence surveillance programs (FISA Section 702, Executive Order 12333) conflict with the fundamental rights of European citizens.",[16,3391,3392],{},"Since July 2023, the EU-US Data Privacy Framework (DPF) exists as a successor agreement. However, data protection experts and Austrian lawyer Max Schrems himself have called it insufficient. The underlying US laws have not changed. A \"Schrems III\" ruling that also invalidates the DPF is considered likely among legal experts.",[16,3394,3395],{},"Organizations that build their statuspage infrastructure on a US provider are therefore accepting a regulatory risk that could materialize at any time.",[11,3397,3399],{"id":3398},"data-processing-agreements-for-saas-statuspages","Data Processing Agreements for SaaS statuspages",[16,3401,3402],{},"Any SaaS statuspage that processes personal data requires a Data Processing Agreement (DPA) under Article 28 of the GDPR. The DPA governs which data is processed, for what purpose, for how long, and with what technical and organizational measures (TOMs) it is protected.",[65,3404,3406],{"id":3405},"what-to-examine-in-a-dpa-review","What to examine in a DPA review",[16,3408,3409,3412],{},[26,3410,3411],{},"Sub-processors."," Most SaaS providers use third-party services — for hosting, email delivery, logging, monitoring. Every sub-processor must be listed in the DPA. Particularly critical: US sub-processors, which can undermine the entire agreement from a GDPR perspective.",[16,3414,3415,3418],{},[26,3416,3417],{},"Data location."," Where exactly is the data stored? Which data centers? Which jurisdiction? A statement like \"EU\" is too vague. Specific locations — Falkenstein, Nuremberg, Helsinki — provide clarity.",[16,3420,3421,3424],{},[26,3422,3423],{},"Deletion policy."," What happens to subscriber data after contract termination? Are monitoring logs automatically deleted? After what period? The right to erasure (Article 17 GDPR) must be technically enforceable.",[16,3426,3427,3430],{},[26,3428,3429],{},"Technical and organizational measures."," Encryption, access controls, audit logs, two-factor authentication — TOMs must reflect the current state of the art and be documented.",[16,3432,3433],{},"With self-hosted solutions, the DPA with the statuspage provider is eliminated entirely. The data never leaves your own network. Responsibility for data protection lies entirely with the operator — but so does control.",[11,3435,3437],{"id":3436},"self-hosting-as-the-gdpr-solution","Self-hosting as the GDPR solution",[16,3439,3440],{},"Self-hosting is the most direct path to data sovereignty. No third-party providers, no sub-processors, no data transfers. The statuspage runs on your own infrastructure, and the data stays within your own network.",[65,3442,3444],{"id":3443},"advantages-from-a-gdpr-perspective","Advantages from a GDPR perspective",[16,3446,3447,3450],{},[26,3448,3449],{},"Full control over data location."," The data resides on your own server — whether in your own data center, with a European hosting provider, or in a private cloud. No third party has access.",[16,3452,3453,3456],{},[26,3454,3455],{},"No DPA with the statuspage vendor."," The software vendor is a licensor, not a data processor. They have no access to the data that the system processes.",[16,3458,3459,3462],{},[26,3460,3461],{},"No sub-processor chain."," The typical chain — statuspage provider uses AWS, AWS uses sub-contractors — does not exist. The operator selects their own hosting provider.",[16,3464,3465,3468],{},[26,3466,3467],{},"Demonstrable compliance."," To data protection authorities, auditors, and customers, the data flow can be documented without gaps. The data demonstrably never leaves your own infrastructure.",[16,3470,3471],{},"LIVCK provides exactly this model: a complete monitoring and statuspage solution that runs via Docker Compose on any Linux server. Installation takes five minutes, and the data stays within your network. For organizations that do not want to operate their own server, LIVCK offers a managed service in German data centers (Falkenstein, Nuremberg) and in Helsinki — all operated by German and European companies.",[11,3473,3475],{"id":3474},"gdpr-checklist-for-statuspage-operators","GDPR checklist for statuspage operators",[16,3477,3478],{},"The following checklist covers the essential verification points relevant to selecting and operating a statuspage from a data protection perspective.",[65,3480,3482],{"id":3481},"provider-and-infrastructure","Provider and infrastructure",[39,3484,3485,3488,3491,3494,3497],{},[42,3486,3487],{},"Where is the statuspage vendor incorporated? EU or third country?",[42,3489,3490],{},"In which country are the servers located where the statuspage is operated?",[42,3492,3493],{},"Is the vendor subject to the US Cloud Act or comparable third-country laws?",[42,3495,3496],{},"Are all sub-processors documented and reviewed?",[42,3498,3499],{},"Is a DPA under Article 28 GDPR in place (for SaaS usage)?",[65,3501,3503],{"id":3502},"data-processing","Data processing",[39,3505,3506,3509,3512,3515,3518],{},[42,3507,3508],{},"Which personal data is collected (subscribers, team members, logs)?",[42,3510,3511],{},"Is the legal basis for each data processing activity documented?",[42,3513,3514],{},"Is there a deletion policy for subscriber data and monitoring logs?",[42,3516,3517],{},"Are subscriber email addresses stored with encryption?",[42,3519,3520],{},"Is double opt-in implemented for subscriber notifications?",[65,3522,3524],{"id":3523},"technical-measures","Technical measures",[39,3526,3527,3530,3533,3536,3539],{},[42,3528,3529],{},"Is the statuspage accessible via HTTPS (TLS 1.2+)?",[42,3531,3532],{},"Is access secured through two-factor authentication?",[42,3534,3535],{},"Are there audit logs for administrative actions?",[42,3537,3538],{},"Is monitoring data encrypted in transit and at rest?",[42,3540,3541],{},"Are cookies used? If so, is a cookie consent banner required?",[65,3543,3545],{"id":3544},"web-analytics-and-tracking","Web analytics and tracking",[39,3547,3548,3551,3554,3557],{},[42,3549,3550],{},"Which analytics tool is deployed?",[42,3552,3553],{},"Are IP addresses stored or anonymized?",[42,3555,3556],{},"Is a cookie consent banner required (for cookie-based tools)?",[42,3558,3559],{},"Can analytics run GDPR-compliant without consent (e.g., Plausible)?",[65,3561,3563],{"id":3562},"data-subject-rights","Data subject rights",[39,3565,3566,3569,3572,3575],{},[42,3567,3568],{},"Can subscribers access their data (right of access, Article 15)?",[42,3570,3571],{},"Can subscribers request deletion of their data (Article 17)?",[42,3573,3574],{},"Can subscribers withdraw consent (Article 7(3))?",[42,3576,3577],{},"Is there a documented process for data subject requests?",[11,3579,3581],{"id":3580},"regulated-industries-and-special-requirements","Regulated industries and special requirements",[16,3583,3584],{},"For organizations in certain industries, requirements beyond the GDPR apply to data processing.",[65,3586,3588],{"id":3587},"data-centers-and-hosting-providers","Data centers and hosting providers",[16,3590,3591],{},"Data center operators who provide statuspages for their customers process availability data that allows direct conclusions about their customers' infrastructure. A data transfer to third countries is particularly sensitive here — not only because of the GDPR but also because of contractual confidentiality obligations.",[65,3593,3595],{"id":3594},"financial-services","Financial services",[16,3597,3598],{},"In the EU, financial institutions are subject to extensive IT outsourcing regulations. In Germany, BaFin-regulated companies must comply with MaRisk requirements. A SaaS statuspage hosted by a US provider may be classified as a material outsourcing arrangement — with corresponding documentation and audit obligations. Since January 2025, the Digital Operational Resilience Act (DORA) has further tightened IT resilience requirements for financial entities across the EU.",[65,3600,3602],{"id":3601},"healthcare","Healthcare",[16,3604,3605],{},"Hospitals, clinics, and health IT service providers process particularly sensitive data under Article 9 of the GDPR. Even if a statuspage itself does not display health data, availability information combined with other data can enable sensitive inferences. National medical confidentiality laws impose additional requirements on data handling.",[65,3607,3609],{"id":3608},"public-sector","Public sector",[16,3611,3612],{},"Government agencies and public institutions are bound by the GDPR and, in many EU member states, by additional national data protection laws. Numerous national data protection authorities have issued explicit recommendations against US cloud services. Self-hosting or the exclusive use of domestic service providers is often the only viable solution.",[11,3614,3616],{"id":3615},"why-the-vendors-jurisdiction-matters","Why the vendor's jurisdiction matters",[16,3618,3619],{},"The GDPR distinguishes between the EU\u002FEEA and third countries. For data transfers to third countries, additional safeguards must be in place — an adequacy decision, Standard Contractual Clauses (SCCs), or Binding Corporate Rules (BCRs).",[16,3621,3622],{},"A European vendor that exclusively uses European data centers eliminates this issue entirely. No third-country transfer, no additional safeguards, no legal uncertainty.",[16,3624,3625],{},"LIVCK is a German company (RServices) that operates its managed service exclusively in data centers in Germany (Falkenstein, Nuremberg) and the EU (Helsinki). All infrastructure is operated by German companies. There is no dependency on US cloud providers, no Cloud Act exposure, no third-country data transfer.",[16,3627,3628],{},"For self-hosted customers, LIVCK goes one step further: the software runs on the customer's own infrastructure. The vendor has no access to the data. Data sovereignty is complete.",[11,3630,3632],{"id":3631},"cookieless-analytics-as-a-building-block","Cookieless analytics as a building block",[16,3634,3635],{},"An often overlooked aspect: the web analytics of the statuspage itself. Anyone who embeds Google Analytics must display a cookie consent banner and obtain visitor consent. This contradicts the purpose of a statuspage — fast, barrier-free information about system status.",[16,3637,3638],{},"Cookieless analytics tools like Plausible do not collect personal data, do not set cookies, and do not require a consent banner. LIVCK uses Plausible, eliminating yet another GDPR concern at its root.",[11,3640,772],{"id":771},[16,3642,3643],{},"GDPR is not a marginal concern for statuspages. Subscriber data, monitoring logs, team accounts, and web analytics generate a substantial volume of personal data. The US Cloud Act and the ongoing legal uncertainty following Schrems II make US providers a calculable but avoidable risk.",[16,3645,3646],{},"The safest approach is a combination of a European vendor and self-hosting — or at minimum, the exclusive use of European data centers. No third-country transfers, no Cloud Act exposure, demonstrable compliance.",[16,3648,3649],{},"For organizations that want to take this path, LIVCK offers precisely that: monitoring and statuspage from Germany, self-hosted or in German data centers, without feature-gating and without compromises on data protection.",{"title":107,"searchDepth":121,"depth":121,"links":3651},[3652,3653,3660,3663,3664,3667,3670,3677,3683,3684,3685],{"id":3307,"depth":121,"text":3308},{"id":3320,"depth":121,"text":3321,"children":3654},[3655,3656,3657,3658,3659],{"id":3327,"depth":331,"text":3328},{"id":3334,"depth":331,"text":3335},{"id":3341,"depth":331,"text":3342},{"id":3348,"depth":331,"text":3349},{"id":3355,"depth":331,"text":3356},{"id":3362,"depth":121,"text":3363,"children":3661},[3662],{"id":3375,"depth":331,"text":3376},{"id":3385,"depth":121,"text":3386},{"id":3398,"depth":121,"text":3399,"children":3665},[3666],{"id":3405,"depth":331,"text":3406},{"id":3436,"depth":121,"text":3437,"children":3668},[3669],{"id":3443,"depth":331,"text":3444},{"id":3474,"depth":121,"text":3475,"children":3671},[3672,3673,3674,3675,3676],{"id":3481,"depth":331,"text":3482},{"id":3502,"depth":331,"text":3503},{"id":3523,"depth":331,"text":3524},{"id":3544,"depth":331,"text":3545},{"id":3562,"depth":331,"text":3563},{"id":3580,"depth":121,"text":3581,"children":3678},[3679,3680,3681,3682],{"id":3587,"depth":331,"text":3588},{"id":3594,"depth":331,"text":3595},{"id":3601,"depth":331,"text":3602},{"id":3608,"depth":331,"text":3609},{"id":3615,"depth":121,"text":3616},{"id":3631,"depth":121,"text":3632},{"id":771,"depth":121,"text":772},"Data Privacy","Why GDPR matters for statuspages, what risks US providers pose, and how self-hosting and European data centers solve the problem.",{},"\u002Fguides\u002Fen\u002Fgdpr-statuspage","dsgvo-statuspage","2026-02-25",[1665,1666,846],[850,1669],{"title":3302,"description":3687},"guides\u002Fen\u002Fgdpr-statuspage","IrhehojGh1-3obivm57LgwBmcvJ3C3qml78RQACnky8",{"id":3698,"title":3699,"body":3700,"category":4471,"description":4472,"extension":836,"faq":837,"meta":4473,"navigation":334,"path":4474,"peerSlug":850,"publishedAt":3691,"readingTime":4475,"relatedComparisons":4476,"relatedGuides":4477,"seo":4479,"stem":4480,"updatedAt":837,"__hash__":4481},"guides\u002Fguides\u002Fen\u002Fself-hosted-statuspage.md","Self-Hosted Statuspage — Why, How and Which Solution?",{"type":8,"value":3701,"toc":4439},[3702,3706,3709,3712,3715,3719,3722,3726,3729,3733,3736,3762,3766,3769,3773,3776,3779,3782,3785,3788,3790,3793,3797,3800,3804,3807,3810,3842,3845,3849,3852,3924,3927,3930,3934,3937,3941,3946,3949,3975,3980,4021,4026,4029,4043,4046,4050,4094,4097,4101,4104,4107,4110,4115,4135,4138,4142,4145,4151,4155,4281,4285,4288,4292,4295,4298,4301,4304,4308,4350,4353,4356,4359,4363,4366,4369,4372,4392,4395,4399,4402,4405,4408,4422,4424,4427,4430,4433,4436],[11,3703,3705],{"id":3704},"why-self-hosting-your-statuspage-matters","Why Self-Hosting Your Statuspage Matters",[16,3707,3708],{},"A statuspage is the public interface for your infrastructure's operational health. Customers, partners and internal teams rely on it to be available and accurate — especially when other systems fail. Placing this critical component in the hands of a third-party cloud provider creates a dependency that quickly becomes problematic in regulated environments or when data sovereignty requirements are non-negotiable.",[16,3710,3711],{},"Self-hosting means the statuspage runs on your own infrastructure. You control where data is stored, who has access and how the system is maintained. No third party sits between you and your users.",[16,3713,3714],{},"Over the past few years, self-hosting has evolved from an enterprise-only proposition to a realistic option for teams of any size. The reason: container technologies like Docker have drastically reduced complexity. What once required weeks of server configuration can now be accomplished with a single command.",[11,3716,3718],{"id":3717},"cloud-vs-self-hosted-an-honest-comparison","Cloud vs. Self-Hosted: An Honest Comparison",[16,3720,3721],{},"Both approaches have their place. The right choice depends on your specific requirements.",[65,3723,3725],{"id":3724},"benefits-of-cloud-statuspages","Benefits of Cloud Statuspages",[16,3727,3728],{},"Cloud solutions like Atlassian Statuspage, Instatus or Better Stack offer a fast start. No server, no maintenance, no deployment. You sign up, configure your services and the statuspage is live. For small teams without DevOps experience or for projects with minimal compliance requirements, this can be perfectly adequate.",[65,3730,3732],{"id":3731},"benefits-of-self-hosted-statuspages","Benefits of Self-Hosted Statuspages",[16,3734,3735],{},"Self-hosting becomes relevant when one or more of the following criteria apply:",[39,3737,3738,3744,3750,3756],{},[42,3739,3740,3743],{},[26,3741,3742],{},"Data sovereignty:"," Monitoring data, incident histories and subscriber lists never leave your network. For organizations subject to GDPR, HIPAA, SOC 2 or industry-specific regulations, this is often not a preference but a requirement.",[42,3745,3746,3749],{},[26,3747,3748],{},"Availability guarantee:"," If your cloud statuspage provider goes down, you cannot communicate precisely when it matters most. A self-hosted solution on separate infrastructure eliminates this dependency.",[42,3751,3752,3755],{},[26,3753,3754],{},"Cost structure:"," Cloud providers often charge per feature, per team member or per statuspage. As teams grow, these costs scale quickly. Self-hosted solutions have predictable, often significantly lower total costs.",[42,3757,3758,3761],{},[26,3759,3760],{},"Customizability:"," Full control over domains, SSL certificates, network routing and integration into existing infrastructure.",[65,3763,3765],{"id":3764},"drawbacks-of-self-hosting","Drawbacks of Self-Hosting",[16,3767,3768],{},"Self-hosting is not maintenance-free. You need a server, must apply updates and are responsible for the instance's availability. For teams with zero Linux experience, this can be a barrier — though modern solutions with auto-updaters and Docker-based deployments have lowered that barrier considerably.",[11,3770,3772],{"id":3771},"regulated-industries-where-self-hosting-becomes-mandatory","Regulated Industries: Where Self-Hosting Becomes Mandatory",[16,3774,3775],{},"In certain industries, the question \"cloud or self-hosted?\" is not a technical preference but a regulatory decision.",[65,3777,3778],{"id":3587},"Data Centers and Hosting Providers",[16,3780,3781],{},"Organizations that operate infrastructure and guarantee SLAs to customers cannot credibly communicate their own status through a third-party cloud service. The irony would be self-evident: \"Our data center is highly available, but our statuspage runs on a shared platform in Virginia.\"",[65,3783,3784],{"id":3594},"Financial Services",[16,3786,3787],{},"Financial institutions subject to regulations like MaRisk (Germany), FCA (UK), SEC\u002FFINRA (US) or similar frameworks face strict requirements around IT outsourcing. A statuspage that processes incident data and subscriber information falls within this scope. Self-hosting on owned or certified infrastructure simplifies compliance significantly.",[65,3789,3602],{"id":3601},[16,3791,3792],{},"Hospitals, insurers and health-tech companies handle particularly sensitive data. Even if a statuspage contains no patient data, the entire IT infrastructure is subject to elevated requirements under frameworks like HIPAA, the EU Medical Device Regulation or national health data protection laws. Self-hosting on systems that already meet industry standards avoids additional audit obligations.",[65,3794,3796],{"id":3795},"government-and-public-sector","Government and Public Sector",[16,3798,3799],{},"Government agencies and public institutions increasingly prioritize digital sovereignty. Self-hosted solutions on domestic infrastructure — whether in Germany, the EU or other jurisdictions — satisfy these requirements directly.",[11,3801,3803],{"id":3802},"docker-as-the-standard-for-self-hosted-software","Docker as the Standard for Self-Hosted Software",[16,3805,3806],{},"Most modern self-hosted applications use Docker as their deployment method. Docker packages an application with all its dependencies into a container that runs identically on any Linux server. This eliminates the classic \"works on my machine\" problem and reduces installation to a few commands.",[16,3808,3809],{},"For statuspages, Docker is particularly sensible:",[39,3811,3812,3818,3824,3836],{},[42,3813,3814,3817],{},[26,3815,3816],{},"Isolation:"," The statuspage runs isolated from the rest of the system. Conflicts with other applications are impossible.",[42,3819,3820,3823],{},[26,3821,3822],{},"Reproducibility:"," The same Docker image runs on a Hetzner server the same way it runs on AWS or in your own data center.",[42,3825,3826,3829,3830,738,3833,1280],{},[26,3827,3828],{},"Updates:"," New versions are shipped as a new image. An update consists of ",[82,3831,3832],{},"docker compose pull",[82,3834,3835],{},"docker compose up -d",[42,3837,3838,3841],{},[26,3839,3840],{},"Rollbacks:"," If an update causes issues, you can revert to the previous version in seconds.",[16,3843,3844],{},"Docker Compose extends Docker with orchestration for multiple containers. A typical statuspage needs the application itself, a database and potentially a reverse proxy. Docker Compose defines all these services in a single YAML file.",[11,3846,3848],{"id":3847},"server-requirements-what-do-you-actually-need","Server Requirements: What Do You Actually Need?",[16,3850,3851],{},"A self-hosted statuspage is not a resource-hungry application. The requirements are modest:",[204,3853,3854,3867],{},[207,3855,3856],{},[210,3857,3858,3861,3864],{},[213,3859,3860],{},"Resource",[213,3862,3863],{},"Minimum",[213,3865,3866],{},"Recommended",[220,3868,3869,3880,3891,3902,3913],{},[210,3870,3871,3874,3877],{},[225,3872,3873],{},"CPU",[225,3875,3876],{},"1 vCPU",[225,3878,3879],{},"2 vCPU",[210,3881,3882,3885,3888],{},[225,3883,3884],{},"RAM",[225,3886,3887],{},"2 GB",[225,3889,3890],{},"4 GB",[210,3892,3893,3896,3899],{},[225,3894,3895],{},"Storage",[225,3897,3898],{},"20 GB SSD",[225,3900,3901],{},"40 GB SSD",[210,3903,3904,3907,3910],{},[225,3905,3906],{},"OS",[225,3908,3909],{},"Linux with Docker support",[225,3911,3912],{},"Ubuntu 22.04+ \u002F Debian 12+",[210,3914,3915,3918,3921],{},[225,3916,3917],{},"Network",[225,3919,3920],{},"Public IP, port 80\u002F443",[225,3922,3923],{},"Static IP, DDoS protection",[16,3925,3926],{},"In practice, a small cloud server from a reputable provider works well. Hetzner Cloud offers suitable instances starting at EUR 4.75 per month — sufficient performance for a statuspage with monitoring that tracks hundreds of services. Other providers like DigitalOcean, Vultr or OVHcloud offer comparable options in various regions.",[16,3928,3929],{},"Important: The server should not share infrastructure with the systems being monitored. If your primary stack runs on AWS, the statuspage should run on a separate provider. Otherwise, the statuspage goes down precisely when you need it most.",[11,3931,3933],{"id":3932},"setting-up-a-self-hosted-statuspage-with-livck","Setting Up a Self-Hosted Statuspage With LIVCK",[16,3935,3936],{},"LIVCK is a monitoring and statuspage solution from Germany that installs via Docker Compose in minutes. Unlike pure statuspage tools, LIVCK combines monitoring, statuspage and incident management in a single application.",[65,3938,3940],{"id":3939},"installation-in-three-steps","Installation in Three Steps",[16,3942,3943],{},[26,3944,3945],{},"Step 1: Prepare your server",[16,3947,3948],{},"On a fresh Linux server with Docker and Docker Compose:",[102,3950,3952],{"className":104,"code":3951,"language":106,"meta":107,"style":107},"# Install Docker (if not already present)\ncurl -fsSL https:\u002F\u002Fget.docker.com | sh\n",[82,3953,3954,3959],{"__ignoreMap":107},[111,3955,3956],{"class":113,"line":114},[111,3957,3958],{"class":117},"# Install Docker (if not already present)\n",[111,3960,3961,3963,3965,3968,3972],{"class":113,"line":121},[111,3962,84],{"class":124},[111,3964,1245],{"class":128},[111,3966,3967],{"class":139}," https:\u002F\u002Fget.docker.com",[111,3969,3971],{"class":3970},"szBVR"," |",[111,3973,3974],{"class":124}," sh\n",[16,3976,3977],{},[26,3978,3979],{},"Step 2: Deploy LIVCK",[102,3981,3983],{"className":104,"code":3982,"language":106,"meta":107,"style":107},"# Download the LIVCK Docker Compose file\ncurl -fsSL https:\u002F\u002Fget.livck.com -o docker-compose.yml\n\n# Start LIVCK\ndocker compose up -d\n",[82,3984,3985,3990,4002,4006,4011],{"__ignoreMap":107},[111,3986,3987],{"class":113,"line":114},[111,3988,3989],{"class":117},"# Download the LIVCK Docker Compose file\n",[111,3991,3992,3994,3996,3998,4000],{"class":113,"line":121},[111,3993,84],{"class":124},[111,3995,1245],{"class":128},[111,3997,1248],{"class":139},[111,3999,164],{"class":128},[111,4001,1253],{"class":139},[111,4003,4004],{"class":113,"line":331},[111,4005,335],{"emptyLinePlaceholder":334},[111,4007,4008],{"class":113,"line":338},[111,4009,4010],{"class":117},"# Start LIVCK\n",[111,4012,4013,4015,4017,4019],{"class":113,"line":344},[111,4014,1258],{"class":124},[111,4016,1261],{"class":139},[111,4018,1264],{"class":139},[111,4020,1267],{"class":128},[16,4022,4023],{},[26,4024,4025],{},"Step 3: Configure your statuspage",[16,4027,4028],{},"After startup, LIVCK is accessible via the server's IP address. The setup wizard guides you through:",[39,4030,4031,4034,4037,4040],{},[42,4032,4033],{},"Account and team creation",[42,4035,4036],{},"First statuspage configuration (theme, domain, branding)",[42,4038,4039],{},"Monitoring checks for your services",[42,4041,4042],{},"Notification integrations (email, Slack, Discord, Telegram, SMS)",[16,4044,4045],{},"The entire process typically takes under five minutes from an empty server to a functioning statuspage.",[65,4047,4049],{"id":4048},"what-livck-provides-in-self-hosted-mode","What LIVCK Provides in Self-Hosted Mode",[39,4051,4052,4058,4064,4070,4076,4082,4088],{},[42,4053,4054,4057],{},[26,4055,4056],{},"Monitoring:"," HTTP(S), TCP, Heartbeat and Manual checks with configurable intervals",[42,4059,4060,4063],{},[26,4061,4062],{},"Statuspage:"," Eclipse theme with visual designer, custom branding, multi-language support, PWA",[42,4065,4066,4069],{},[26,4067,4068],{},"Incident Management:"," Five status stages, outage linking, announcements, maintenance windows",[42,4071,4072,4075],{},[26,4073,4074],{},"Notifications:"," Email, Slack, Discord, Telegram, SMS, Pushover with throttling",[42,4077,4078,4081],{},[26,4079,4080],{},"API:"," Public & Private API for automation and integration",[42,4083,4084,4087],{},[26,4085,4086],{},"Team:"," Multiple members per plan, granular permissions, two-factor authentication",[42,4089,4090,4093],{},[26,4091,4092],{},"Auto-Updater:"," LIVCK updates itself automatically without manual intervention",[16,4095,4096],{},"Crucially, all features are available in every plan. There is no feature-gating where basic functionality is locked behind more expensive tiers.",[11,4098,4100],{"id":4099},"comparison-with-open-source-alternatives","Comparison With Open-Source Alternatives",[16,4102,4103],{},"Two open-source projects are frequently mentioned in the context of self-hosted statuspages: Uptime Kuma and CachetHQ. Both have their merits, but also clear limitations.",[65,4105,1075],{"id":4106},"uptime-kuma",[16,4108,4109],{},"Uptime Kuma is a popular open-source monitoring tool with a built-in, rudimentary statuspage. It is quick to install and provides solid uptime monitoring for personal projects and small teams.",[16,4111,4112],{},[26,4113,4114],{},"Limitations:",[39,4116,4117,4120,4123,4126,4129,4132],{},[42,4118,4119],{},"The statuspage is minimal: no custom branding, no visual designer, no themes",[42,4121,4122],{},"No real incident management (no status stages, no outage linking)",[42,4124,4125],{},"No subscriber notifications (users cannot subscribe to status updates)",[42,4127,4128],{},"No API for the statuspage itself",[42,4130,4131],{},"Single-user application — no team features, no role-based permissions",[42,4133,4134],{},"No professional support or SLA",[16,4136,4137],{},"Uptime Kuma excels as a personal monitoring dashboard. As a public-facing statuspage for an organization, it lacks essential functionality.",[65,4139,4141],{"id":4140},"cachethq","CachetHQ",[16,4143,4144],{},"CachetHQ was the most well-known open-source statuspage project. It offered a solid statuspage with incident tracking and subscriber management.",[16,4146,4147,4150],{},[26,4148,4149],{},"The problem:"," CachetHQ has not been actively maintained for years. The last substantial update is far in the past. Open security issues, incompatibility with current PHP versions and absent support make it unsuitable for production use. Additionally, CachetHQ provides no monitoring whatsoever — you need a separate tool to even detect outages.",[65,4152,4154],{"id":4153},"livck-in-comparison","LIVCK in Comparison",[204,4156,4157,4170],{},[207,4158,4159],{},[210,4160,4161,4164,4166,4168],{},[213,4162,4163],{},"Feature",[213,4165,1075],{},[213,4167,4141],{},[213,4169,635],{},[220,4171,4172,4182,4196,4208,4220,4233,4245,4256,4267],{},[210,4173,4174,4176,4178,4180],{},[225,4175,834],{},[225,4177,980],{},[225,4179,999],{},[225,4181,980],{},[210,4183,4184,4187,4190,4193],{},[225,4185,4186],{},"Statuspage",[225,4188,4189],{},"Basic",[225,4191,4192],{},"Yes (outdated)",[225,4194,4195],{},"Yes (designer, custom branding)",[210,4197,4198,4200,4202,4205],{},[225,4199,1097],{},[225,4201,999],{},[225,4203,4204],{},"Simple",[225,4206,4207],{},"Yes (5 stages, linking)",[210,4209,4210,4213,4215,4217],{},[225,4211,4212],{},"Subscriber System",[225,4214,999],{},[225,4216,980],{},[225,4218,4219],{},"Yes (newsletter, PWA)",[210,4221,4222,4225,4227,4230],{},[225,4223,4224],{},"Team Features",[225,4226,999],{},[225,4228,4229],{},"Limited",[225,4231,4232],{},"Yes (members per plan, roles)",[210,4234,4235,4238,4240,4242],{},[225,4236,4237],{},"API",[225,4239,4229],{},[225,4241,980],{},[225,4243,4244],{},"Public & Private API",[210,4246,4247,4250,4252,4254],{},[225,4248,4249],{},"Auto-Updater",[225,4251,999],{},[225,4253,999],{},[225,4255,980],{},[210,4257,4258,4261,4263,4265],{},[225,4259,4260],{},"Actively Maintained",[225,4262,980],{},[225,4264,999],{},[225,4266,980],{},[210,4268,4269,4272,4275,4278],{},[225,4270,4271],{},"Support",[225,4273,4274],{},"Community",[225,4276,4277],{},"None",[225,4279,4280],{},"Professional",[11,4282,4284],{"id":4283},"cost-analysis-self-hosted-vs-cloud-providers","Cost Analysis: Self-Hosted vs. Cloud Providers",[16,4286,4287],{},"An honest cost comparison reveals why self-hosting is economically compelling.",[65,4289,4291],{"id":4290},"cloud-providers-typical-costs","Cloud Providers: Typical Costs",[16,4293,4294],{},"Atlassian Statuspage charges from USD 99 per month for the Startup plan. Custom branding and advanced features require USD 399 per month. Monitoring is not included — you need a separate tool for that.",[16,4296,4297],{},"Better Stack starts free, but usable plans with sufficient monitors and statuspage features quickly reach USD 80 to 150 per month.",[16,4299,4300],{},"Instatus offers a lower entry point at USD 20 with basic monitoring, but advanced features cost up to USD 300 per month.",[16,4302,4303],{},"For international teams, these USD-denominated prices also carry currency risk and often increase at renewal.",[65,4305,4307],{"id":4306},"self-hosted-with-livck-total-cost","Self-Hosted With LIVCK: Total Cost",[204,4309,4310,4320],{},[207,4311,4312],{},[210,4313,4314,4317],{},[213,4315,4316],{},"Item",[213,4318,4319],{},"Cost per Month",[220,4321,4322,4330,4338],{},[210,4323,4324,4327],{},[225,4325,4326],{},"Server (Hetzner Cloud, CX22)",[225,4328,4329],{},"EUR 4.75",[210,4331,4332,4335],{},[225,4333,4334],{},"LIVCK Starter license",[225,4336,4337],{},"EUR 9.90",[210,4339,4340,4345],{},[225,4341,4342],{},[26,4343,4344],{},"Total",[225,4346,4347],{},[26,4348,4349],{},"EUR 14.65",[16,4351,4352],{},"For EUR 14.65 per month, you get monitoring and statuspage in one tool, on your own server, with full data control. For comparison: Atlassian Statuspage alone — without monitoring — costs five times as much on the Startup plan.",[16,4354,4355],{},"Even the Business plan (EUR 39.90) with the recommended server (EUR 4.75) comes to under EUR 45 per month — a fraction of what comparable cloud solutions charge.",[16,4357,4358],{},"For teams that cannot carry license costs: LIVCK's Smart plan is free and includes 20 monitors, 5 categories and one user. The server cost of under five euros per month remains the only expense.",[11,4360,4362],{"id":4361},"auto-updates-and-maintenance","Auto-Updates and Maintenance",[16,4364,4365],{},"A common argument against self-hosting is the maintenance overhead. With LIVCK, this overhead is minimal.",[16,4367,4368],{},"The built-in auto-updater regularly checks for new versions and applies updates automatically. You do not need to manually pull Docker images or run database migrations. The system updates itself and notifies you of completed updates.",[16,4370,4371],{},"For the server itself, recommended practices include:",[39,4373,4374,4380,4386],{},[42,4375,4376,4379],{},[26,4377,4378],{},"Unattended upgrades"," for the operating system",[42,4381,4382,4385],{},[26,4383,4384],{},"Regular backups"," of the database (cron job, daily export)",[42,4387,4388,4391],{},[26,4389,4390],{},"Monitoring the server itself"," — ideally from an external location",[16,4393,4394],{},"The actual time investment for maintaining a self-hosted LIVCK instance is a few minutes per month when the auto-updater is active.",[11,4396,4398],{"id":4397},"managed-service-the-middle-ground","Managed Service: The Middle Ground",[16,4400,4401],{},"Not every team has the capacity or expertise to operate its own server. At the same time, compliance requirements may be too strict for US-based cloud providers.",[16,4403,4404],{},"LIVCK offers a managed service for exactly this scenario: LIVCK runs on dedicated German servers, maintained and updated by the LIVCK team. You get the benefits of self-hosting — data sovereignty, German data centers, full configuration control — without administering a server yourself.",[16,4406,4407],{},"This is particularly relevant for:",[39,4409,4410,4413,4416,4419],{},[42,4411,4412],{},"Organizations without a dedicated DevOps team",[42,4414,4415],{},"Companies that need to demonstrate GDPR compliance but do not operate internal hosting",[42,4417,4418],{},"Teams that want to start quickly and take over server administration later",[42,4420,4421],{},"International organizations that need EU-based data processing for regulatory reasons",[11,4423,772],{"id":771},[16,4425,4426],{},"Self-hosted statuspages are no longer a niche solution. Docker has lowered the barrier to entry to the point where a working setup takes minutes, not days. The benefits — data sovereignty, independence, predictable costs — clearly outweigh the manageable maintenance effort.",[16,4428,4429],{},"For organizations in regulated industries, self-hosting is often the only viable option. For everyone else, it is an economically and technically sound alternative to cloud providers that rely on escalating prices and feature-gating.",[16,4431,4432],{},"LIVCK provides monitoring and statuspage functionality from a single tool, built in Germany: self-hosted via Docker Compose, optionally as a managed service — the cloud variant is in public beta. Automatic updates and professional support included.",[16,4434,4435],{},"If your statuspage is critical to your operations — and it should be — the control over it should remain in your hands.",[812,4437,4438],{},"html pre.shiki code .sJ8bj, html code.shiki .sJ8bj{--shiki-default:#6A737D;--shiki-dark:#6A737D}html pre.shiki code .sScJk, html code.shiki .sScJk{--shiki-default:#6F42C1;--shiki-dark:#B392F0}html pre.shiki code .sj4cs, html code.shiki .sj4cs{--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .sZZnC, html code.shiki .sZZnC{--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .szBVR, html code.shiki .szBVR{--shiki-default:#D73A49;--shiki-dark:#F97583}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":107,"searchDepth":121,"depth":121,"links":4440},[4441,4442,4447,4453,4454,4455,4459,4464,4468,4469,4470],{"id":3704,"depth":121,"text":3705},{"id":3717,"depth":121,"text":3718,"children":4443},[4444,4445,4446],{"id":3724,"depth":331,"text":3725},{"id":3731,"depth":331,"text":3732},{"id":3764,"depth":331,"text":3765},{"id":3771,"depth":121,"text":3772,"children":4448},[4449,4450,4451,4452],{"id":3587,"depth":331,"text":3778},{"id":3594,"depth":331,"text":3784},{"id":3601,"depth":331,"text":3602},{"id":3795,"depth":331,"text":3796},{"id":3802,"depth":121,"text":3803},{"id":3847,"depth":121,"text":3848},{"id":3932,"depth":121,"text":3933,"children":4456},[4457,4458],{"id":3939,"depth":331,"text":3940},{"id":4048,"depth":331,"text":4049},{"id":4099,"depth":121,"text":4100,"children":4460},[4461,4462,4463],{"id":4106,"depth":331,"text":1075},{"id":4140,"depth":331,"text":4141},{"id":4153,"depth":331,"text":4154},{"id":4283,"depth":121,"text":4284,"children":4465},[4466,4467],{"id":4290,"depth":331,"text":4291},{"id":4306,"depth":331,"text":4307},{"id":4361,"depth":121,"text":4362},{"id":4397,"depth":121,"text":4398},{"id":771,"depth":121,"text":772},"Self-Hosting","Self-hosted vs. cloud statuspage: benefits, requirements, Docker setup and comparison with open-source alternatives like Uptime Kuma and CachetHQ.",{},"\u002Fguides\u002Fen\u002Fself-hosted-statuspage",11,[4106,1665,1666],[4478,1669],"gdpr-statuspage",{"title":3699,"description":4472},"guides\u002Fen\u002Fself-hosted-statuspage","g2-mt41sfwS9sAFufKq6AAE71BvUtzglu9Fi6Nl_PWw",{"id":4483,"title":4484,"body":4485,"category":5005,"description":5006,"extension":836,"faq":837,"meta":5007,"navigation":334,"path":5008,"peerSlug":2242,"publishedAt":3691,"readingTime":4475,"relatedComparisons":5009,"relatedGuides":5011,"seo":5012,"stem":5013,"updatedAt":837,"__hash__":5014},"guides\u002Fguides\u002Fen\u002Fstatuspage-best-practices.md","Statuspage Best Practices — Transparency, Design & Incident Communication",{"type":8,"value":4486,"toc":4948},[4487,4491,4494,4497,4500,4503,4507,4510,4514,4517,4521,4524,4528,4531,4535,4538,4542,4547,4552,4558,4564,4570,4576,4581,4587,4593,4596,4599,4603,4607,4610,4630,4634,4637,4641,4644,4664,4667,4671,4674,4678,4681,4684,4688,4691,4695,4698,4702,4705,4709,4712,4716,4723,4727,4730,4733,4737,4740,4744,4747,4750,4753,4756,4760,4763,4767,4770,4774,4777,4781,4784,4788,4791,4795,4798,4802,4822,4825,4829,4833,4836,4840,4843,4847,4850,4854,4858,4861,4865,4868,4872,4875,4879,4882,4886,4889,4893,4896,4900,4903,4907,4910,4914,4917,4919,4922,4942,4945],[11,4488,4490],{"id":4489},"why-a-well-run-statuspage-matters","Why a Well-Run Statuspage Matters",[16,4492,4493],{},"A statuspage is more than a technical information display. It is the public face of your infrastructure and a direct communication channel between your engineering team and every user who depends on your service. In a world where downtime is inevitable, the quality of your statuspage determines whether users build trust or lose it.",[16,4495,4496],{},"The impact of a professionally maintained statuspage is measurable. Support teams consistently report a 30 to 50 percent reduction in incoming tickets during incidents when a statuspage is actively updated. Users who can inform themselves do not open tickets. They check the statuspage, see the current state, and wait.",[16,4498,4499],{},"Beyond ticket deflection, a statuspage is an instrument of customer retention. Companies that handle outages openly are perceived as more trustworthy than those that stay silent. Transparency is not a sign of weakness. It is a sign of professional maturity.",[16,4501,4502],{},"This guide covers the essential best practices that transform a statuspage from a forgotten subpage into a strategic communication tool.",[11,4504,4506],{"id":4505},"transparent-communication-as-a-core-principle","Transparent Communication as a Core Principle",[16,4508,4509],{},"The most important rule for any statuspage: honesty over perfection. Users forgive outages. What they do not forgive is the feeling of being left in the dark.",[65,4511,4513],{"id":4512},"proactive-over-reactive","Proactive Over Reactive",[16,4515,4516],{},"An incident should appear on the statuspage before the first support tickets arrive. If you wait until users report the problem, you have already lost the communication advantage. The statuspage is then no longer perceived as an information source but as a belated confirmation of what users already know.",[65,4518,4520],{"id":4519},"plain-language-over-technical-jargon","Plain Language Over Technical Jargon",[16,4522,4523],{},"Statuspage updates must be understandable for all audiences. Not every reader is an engineer. An update like \"We are investigating increased error rates on the login service\" is better than \"HTTP 503 on auth-service-prod-3 after OOM kill in k8s cluster.\" Technical details belong in the post-mortem, not in the live update.",[65,4525,4527],{"id":4526},"no-finger-pointing","No Finger-Pointing",[16,4529,4530],{},"A statuspage update describes the problem and the progress. It does not blame third-party providers, individual teams, or specific people. The phrasing \"Our cloud provider has reported a network issue affecting our service\" is factual and professional.",[11,4532,4534],{"id":4533},"using-status-levels-effectively","Using Status Levels Effectively",[16,4536,4537],{},"A well-designed incident workflow gives every outage a clear structure. Instead of toggling between \"down\" and \"resolved,\" differentiated status levels allow precise communication of progress.",[65,4539,4541],{"id":4540},"the-5-stage-workflow-in-detail","The 5-Stage Workflow in Detail",[16,4543,4544,4546],{},[26,4545,1882],{}," — The starting point. A problem has been detected, the cause is unknown. A brief notice is sufficient: \"We are investigating reports of limited dashboard availability.\"",[16,4548,4549,4551],{},[26,4550,1890],{}," — The root cause has been found. The team now knows what went wrong. \"The root cause has been identified: a faulty database migration is causing read timeouts.\"",[16,4553,4554,4557],{},[26,4555,4556],{},"Acknowledged"," — The problem is recognized and prioritized, but the fix requires time. Particularly relevant for issues that cannot be resolved immediately.",[16,4559,4560,4563],{},[26,4561,4562],{},"In Progress"," — Active work on the fix. Users see that something is happening. \"The team is performing a rollback of the database schema changes.\"",[16,4565,4566,4569],{},[26,4567,4568],{},"Observing"," — The fix has been deployed, the team is monitoring. \"The fix has been rolled out. We are monitoring systems for the next 30 minutes.\"",[16,4571,4572,4575],{},[26,4573,4574],{},"Under Review"," — Post-fix evaluation is underway. The incident is technically resolved, but the team is still checking for residual effects.",[16,4577,4578,4580],{},[26,4579,1905],{}," — Everything is back to normal. Brief summary of what happened and what was done.",[16,4582,4583,4586],{},[26,4584,4585],{},"Scheduled"," — For planned maintenance. Users are informed in advance.",[16,4588,4589,4592],{},[26,4590,4591],{},"Closed"," — The incident is completed and archived.",[16,4594,4595],{},"The advantage of this model: users never have to guess where in the process the team currently is. Every status transition is a signal that active work is happening.",[16,4597,4598],{},"LIVCK implements this entire workflow natively. Every stage is built into the incident management system, including automatic notifications on status transitions.",[11,4600,4602],{"id":4601},"incident-updates-frequency-tone-and-content","Incident Updates: Frequency, Tone, and Content",[65,4604,4606],{"id":4605},"frequency","Frequency",[16,4608,4609],{},"During an active incident, the rule is: one update too many is better than one too few. A proven cadence:",[39,4611,4612,4618,4624],{},[42,4613,4614,4617],{},[26,4615,4616],{},"First 30 minutes:"," An update every 10 to 15 minutes, even if it only says \"Still investigating.\"",[42,4619,4620,4623],{},[26,4621,4622],{},"After 30 minutes:"," Every 20 to 30 minutes, provided the status is changing.",[42,4625,4626,4629],{},[26,4627,4628],{},"For extended incidents:"," At least once per hour. Users who see no updates assume that nobody is working on the problem.",[65,4631,4633],{"id":4632},"tone","Tone",[16,4635,4636],{},"Statuspage updates should be factual, calm, and solution-oriented. Neither panic nor minimization is appropriate. Phrases like \"minor issue\" or \"minimal impact\" are only acceptable when they match reality. Users who cannot access their service rarely perceive the impact as minimal.",[65,4638,4640],{"id":4639},"content-of-a-good-update","Content of a Good Update",[16,4642,4643],{},"Every update should contain three elements:",[73,4645,4646,4652,4658],{},[42,4647,4648,4651],{},[26,4649,4650],{},"Current state"," — What is happening right now?",[42,4653,4654,4657],{},[26,4655,4656],{},"Next step"," — What is being done next?",[42,4659,4660,4663],{},[26,4661,4662],{},"Expected timeline"," — When should users expect the next update?",[16,4665,4666],{},"An example: \"The login service remains degraded. The team has identified the cause as a corrupted cache entry and is currently performing a cache flush. We expect restoration within the next 15 minutes and will provide another update by 2:30 PM UTC at the latest.\"",[11,4668,4670],{"id":4669},"informing-subscribers-the-right-way","Informing Subscribers the Right Way",[16,4672,4673],{},"A statuspage that nobody visits serves no purpose. A functioning notification system is therefore essential.",[65,4675,4677],{"id":4676},"think-multi-channel","Think Multi-Channel",[16,4679,4680],{},"Not every user checks a website regularly. Professional statuspages offer notifications through multiple channels: email, Slack, Discord, Telegram, SMS. The choice of channel should be up to the user.",[16,4682,4683],{},"LIVCK natively supports email, Discord (webhook and bot), Slack, Telegram, SMS, and Pushover. All channels include throttling to prevent notification floods during major incidents.",[65,4685,4687],{"id":4686},"newsletter-subscribers-vs-incident-subscribers","Newsletter Subscribers vs. Incident Subscribers",[16,4689,4690],{},"There is an important distinction between users who want to be notified about incidents and those who want general updates or announcements. A good statuspage supports both models and lets users decide which notifications they receive.",[65,4692,4694],{"id":4693},"using-announcements","Using Announcements",[16,4696,4697],{},"Not every piece of communication is an incident. Planned migrations, new features, or infrastructure changes can be communicated through announcements without opening an incident. This keeps the incident history clean and gives the team a dedicated channel for proactive communication.",[11,4699,4701],{"id":4700},"design-and-branding-projecting-professionalism","Design and Branding: Projecting Professionalism",[16,4703,4704],{},"The statuspage is often the first touchpoint during a crisis. The standards for design and branding must reflect this.",[65,4706,4708],{"id":4707},"consistent-branding","Consistent Branding",[16,4710,4711],{},"The statuspage should visually belong to the main product. Same colors, same logo, same typography. A statuspage that looks like a foreign body undermines trust. Users wonder if they have landed on the right page.",[65,4713,4715],{"id":4714},"custom-domain","Custom Domain",[16,4717,4718,4719,4722],{},"A statuspage at ",[82,4720,4721],{},"status.yourproduct.com"," looks more professional than a generic subdomain of a third-party provider. Custom domains signal that the statuspage is an integral part of the product, not an afterthought.",[65,4724,4726],{"id":4725},"clarity-over-creativity","Clarity Over Creativity",[16,4728,4729],{},"Statuspage design should prioritize information, not aesthetics. Large, clearly readable status indicators. Color coding for different states. No cluttered layouts. A user must be able to determine within three seconds whether everything is operational or whether there is a problem.",[16,4731,4732],{},"LIVCK offers full custom branding: logo, colors, custom CSS and custom domains are included in every plan.",[11,4734,4736],{"id":4735},"monitoring-integration-why-monitoring-and-statuspage-belong-together","Monitoring Integration: Why Monitoring and Statuspage Belong Together",[16,4738,4739],{},"A statuspage without monitoring is reactive. The team learns about problems only when users report them. By the time the statuspage is updated, the incident has already caused damage.",[65,4741,4743],{"id":4742},"automatic-detection-over-manual-reporting","Automatic Detection Over Manual Reporting",[16,4745,4746],{},"When monitoring and statuspage are integrated in one system, incidents can be triggered automatically as soon as a check fails. This reduces the mean time to notify dramatically.",[65,4748,2133],{"id":4749},"outage-linking",[16,4751,4752],{},"An advanced concept is the automatic association of incidents with affected services. When the monitoring check for the API server fails, the corresponding service on the statuspage is automatically marked as affected. This outage linking eliminates manual steps and ensures the statuspage always reflects the actual system state.",[16,4754,4755],{},"LIVCK implements outage linking natively, connecting incidents with the services they affect without requiring manual intervention from the on-call engineer.",[65,4757,4759],{"id":4758},"false-alarm-protection","False Alarm Protection",[16,4761,4762],{},"Not every failed check is a real outage. Network glitches, transient DNS issues, or brief timeouts can trigger false alarms. A good system filters these out before an incident is created. LIVCK therefore confirms an outage from multiple independent locations before an incident is created, preventing unnecessary noise on the statuspage and in notification channels.",[11,4764,4766],{"id":4765},"communicating-maintenance-windows-professionally","Communicating Maintenance Windows Professionally",[16,4768,4769],{},"Planned maintenance is not an incident. It deserves its own communication strategy.",[65,4771,4773],{"id":4772},"lead-time","Lead Time",[16,4775,4776],{},"Users should be notified at least 48 hours before scheduled maintenance. For larger changes with potential downtime, 5 to 7 days is appropriate. The announcement should clearly state the time window, the affected services, and the expected impact.",[65,4778,4780],{"id":4779},"maintenance-windows-with-start-and-end-times","Maintenance Windows with Start and End Times",[16,4782,4783],{},"Vague statements like \"over the weekend\" are insufficient. Professional maintenance communication specifies exact times: \"Saturday, March 15, 2026, 02:00 to 04:00 UTC.\" Users can plan accordingly and inform their own stakeholders.",[65,4785,4787],{"id":4786},"status-during-maintenance","Status During Maintenance",[16,4789,4790],{},"Even during planned maintenance, the statuspage should be updated. A status like \"Maintenance is proceeding as planned\" reassures users. If the maintenance takes longer than expected, an update becomes even more critical.",[11,4792,4794],{"id":4793},"private-statuspages-for-internal-teams","Private Statuspages for Internal Teams",[16,4796,4797],{},"Not every statuspage is public. Internal statuspages for DevOps teams, management, or partners provide a protected communication channel with more technical detail.",[65,4799,4801],{"id":4800},"use-cases","Use Cases",[39,4803,4804,4810,4816],{},[42,4805,4806,4809],{},[26,4807,4808],{},"Internal infrastructure:"," Databases, message queues, internal APIs that end users never interact with directly.",[42,4811,4812,4815],{},[26,4813,4814],{},"Partner integrations:"," Status overview for B2B partners who depend on your API.",[42,4817,4818,4821],{},[26,4819,4820],{},"Regulated industries:"," Financial services, healthcare, or public sector organizations where certain information must not be publicly accessible.",[16,4823,4824],{},"Private pages with access control are included in every LIVCK plan. Teams can operate multiple statuspages for different audiences without needing separate tools.",[11,4826,4828],{"id":4827},"uptime-metrics-and-sla-transparency","Uptime Metrics and SLA Transparency",[65,4830,4832],{"id":4831},"uptime-calendar","Uptime Calendar",[16,4834,4835],{},"An uptime calendar shows historical availability at a glance. Users see not only the current status but also the reliability track record over past weeks and months. This transparency builds long-term trust and is often the first thing prospective customers evaluate.",[65,4837,4839],{"id":4838},"sla-tracking","SLA Tracking",[16,4841,4842],{},"For B2B customers, service level agreements are not a formality but contractual obligations. A statuspage that openly displays SLA metrics demonstrates that the organization takes its own commitments seriously. It also provides a shared reference point for conversations between vendor and customer.",[65,4844,4846],{"id":4845},"badges","Badges",[16,4848,4849],{},"Uptime badges embedded in documentation, repositories, or marketing pages are a simple but effective way to make availability visible. They serve as both a trust signal and a quick link to the statuspage. When availability is high, badges are a source of pride. When it drops, they are an incentive to improve.",[11,4851,4853],{"id":4852},"common-mistakes-and-how-to-avoid-them","Common Mistakes and How to Avoid Them",[65,4855,4857],{"id":4856},"mistake-1-only-updating-the-statuspage-during-major-outages","Mistake 1: Only Updating the Statuspage During Major Outages",[16,4859,4860],{},"Minor degradations belong on the statuspage too. If you only communicate during total outages, you train users not to trust the statuspage. When it always shows \"All Systems Operational\" despite users regularly experiencing issues, the page loses credibility.",[65,4862,4864],{"id":4863},"mistake-2-communicating-too-late","Mistake 2: Communicating Too Late",[16,4866,4867],{},"The most common mistake. The team wants to find the root cause before communicating. But users do not want to wait for a diagnosis. They want to know that the problem is acknowledged and someone is working on it. The first update can be as simple as: \"We are aware of issues affecting the dashboard and are investigating.\"",[65,4869,4871],{"id":4870},"mistake-3-no-post-mortem-after-major-incidents","Mistake 3: No Post-Mortem After Major Incidents",[16,4873,4874],{},"After a significant outage, users expect a thorough review. What happened? Why? What is being done to prevent recurrence? A post-mortem is not an admission of failure. It is proof of a functioning engineering process. The best post-mortems are blameless, specific, and include concrete action items.",[65,4876,4878],{"id":4877},"mistake-4-running-monitoring-and-statuspage-as-separate-systems","Mistake 4: Running Monitoring and Statuspage as Separate Systems",[16,4880,4881],{},"When the monitoring tool and the statuspage are not integrated, a manual process emerges: someone has to notice the outage, open the statuspage tool, and manually create an incident. This costs time and is error-prone. Integrated solutions like LIVCK eliminate this gap entirely.",[65,4883,4885],{"id":4884},"mistake-5-generic-design-with-no-brand-identity","Mistake 5: Generic Design With No Brand Identity",[16,4887,4888],{},"A statuspage that looks like a thousand others is not perceived as part of your product. Custom branding is not a luxury. It is a baseline requirement for professional external communication. Your statuspage should look like it was built by the same team that built your product.",[11,4890,4892],{"id":4891},"building-a-statuspage-culture","Building a Statuspage Culture",[16,4894,4895],{},"Technical implementation is only half the equation. The other half is organizational discipline.",[65,4897,4899],{"id":4898},"define-clear-ownership","Define Clear Ownership",[16,4901,4902],{},"Every team should know who is responsible for updating the statuspage during an incident. Ambiguity leads to delays. Whether it is the on-call engineer, a dedicated incident commander, or an automated system, the responsibility must be explicit.",[65,4904,4906],{"id":4905},"create-templates","Create Templates",[16,4908,4909],{},"Pre-written update templates for common scenarios accelerate response time. A template for \"Database degradation,\" \"Third-party provider outage,\" or \"Scheduled maintenance extended\" means the on-call engineer does not have to compose prose under pressure.",[65,4911,4913],{"id":4912},"review-and-iterate","Review and Iterate",[16,4915,4916],{},"After every major incident, review how the statuspage communication went. Was the first update timely? Were the status transitions accurate? Did subscribers receive notifications promptly? Each incident is an opportunity to improve the process.",[11,4918,772],{"id":771},[16,4920,4921],{},"A professional statuspage is not a side project. It is a strategic communication tool that builds trust, reduces support costs, and strengthens the relationship with users. The best practices distill into three core principles:",[73,4923,4924,4930,4936],{},[42,4925,4926,4929],{},[26,4927,4928],{},"Transparency:"," Communicate early, communicate honestly, communicate regularly.",[42,4931,4932,4935],{},[26,4933,4934],{},"Structure:"," Clear status levels, defined processes, consistent updates.",[42,4937,4938,4941],{},[26,4939,4940],{},"Integration:"," Monitoring and statuspage belong together. Manual processes lead to delays and errors.",[16,4943,4944],{},"LIVCK combines monitoring and statuspage in a single solution, with a full incident workflow, auto-detection, postmortems, multi-channel notifications, and full custom branding. Available as a self-hosted installation and as a cloud service, with all features included in every plan.",[16,4946,4947],{},"Organizations that commit to these best practices transform their statuspage from a technical obligation into a genuine competitive advantage.",{"title":107,"searchDepth":121,"depth":121,"links":4949},[4950,4951,4956,4959,4964,4969,4974,4979,4984,4987,4992,4999,5004],{"id":4489,"depth":121,"text":4490},{"id":4505,"depth":121,"text":4506,"children":4952},[4953,4954,4955],{"id":4512,"depth":331,"text":4513},{"id":4519,"depth":331,"text":4520},{"id":4526,"depth":331,"text":4527},{"id":4533,"depth":121,"text":4534,"children":4957},[4958],{"id":4540,"depth":331,"text":4541},{"id":4601,"depth":121,"text":4602,"children":4960},[4961,4962,4963],{"id":4605,"depth":331,"text":4606},{"id":4632,"depth":331,"text":4633},{"id":4639,"depth":331,"text":4640},{"id":4669,"depth":121,"text":4670,"children":4965},[4966,4967,4968],{"id":4676,"depth":331,"text":4677},{"id":4686,"depth":331,"text":4687},{"id":4693,"depth":331,"text":4694},{"id":4700,"depth":121,"text":4701,"children":4970},[4971,4972,4973],{"id":4707,"depth":331,"text":4708},{"id":4714,"depth":331,"text":4715},{"id":4725,"depth":331,"text":4726},{"id":4735,"depth":121,"text":4736,"children":4975},[4976,4977,4978],{"id":4742,"depth":331,"text":4743},{"id":4749,"depth":331,"text":2133},{"id":4758,"depth":331,"text":4759},{"id":4765,"depth":121,"text":4766,"children":4980},[4981,4982,4983],{"id":4772,"depth":331,"text":4773},{"id":4779,"depth":331,"text":4780},{"id":4786,"depth":331,"text":4787},{"id":4793,"depth":121,"text":4794,"children":4985},[4986],{"id":4800,"depth":331,"text":4801},{"id":4827,"depth":121,"text":4828,"children":4988},[4989,4990,4991],{"id":4831,"depth":331,"text":4832},{"id":4838,"depth":331,"text":4839},{"id":4845,"depth":331,"text":4846},{"id":4852,"depth":121,"text":4853,"children":4993},[4994,4995,4996,4997,4998],{"id":4856,"depth":331,"text":4857},{"id":4863,"depth":331,"text":4864},{"id":4870,"depth":331,"text":4871},{"id":4877,"depth":331,"text":4878},{"id":4884,"depth":331,"text":4885},{"id":4891,"depth":121,"text":4892,"children":5000},[5001,5002,5003],{"id":4898,"depth":331,"text":4899},{"id":4905,"depth":331,"text":4906},{"id":4912,"depth":331,"text":4913},{"id":771,"depth":121,"text":772},"Best Practices","The most important best practices for statuspages: transparent communication, proper incident management, professional design and monitoring integration.",{},"\u002Fguides\u002Fen\u002Fstatuspage-best-practices",[1665,1667,5010],"hyperping",[1669,850],{"title":4484,"description":5006},"guides\u002Fen\u002Fstatuspage-best-practices","rKorgsy9A22r-xOwxWVSKLcU0DeNgJOfh9pt919u9Mo",{"id":5016,"title":5017,"body":5018,"category":5395,"description":5396,"extension":836,"faq":5397,"meta":5405,"navigation":334,"path":5406,"peerSlug":5407,"publishedAt":3691,"readingTime":3294,"relatedComparisons":5408,"relatedGuides":5409,"seo":5410,"stem":5411,"updatedAt":837,"__hash__":5412},"guides\u002Fguides\u002Fen\u002Fwhat-is-a-statuspage.md","What Is a Statuspage? — Definition, Benefits & Best Practices",{"type":8,"value":5019,"toc":5350},[5020,5023,5026,5032,5035,5038,5042,5046,5049,5053,5056,5060,5063,5067,5070,5074,5077,5081,5084,5088,5091,5095,5098,5102,5105,5109,5112,5116,5119,5123,5126,5130,5134,5137,5140,5144,5147,5151,5154,5158,5161,5165,5168,5172,5175,5179,5182,5186,5189,5193,5196,5200,5203,5207,5210,5214,5217,5221,5224,5227,5231,5235,5238,5242,5245,5249,5252,5256,5259,5263,5266,5270,5273,5279,5285,5291,5296,5302,5306,5309,5315,5321,5327,5333,5339,5341,5344,5347],[11,5021,5022],{"id":1669},"What Is a Statuspage?",[16,5024,5025],{},"A statuspage is a publicly accessible web page that displays the real-time operational status of a company's services and systems. It serves as a single source of truth for customers, partners, and internal teams to check availability, view ongoing incidents, review scheduled maintenance, and assess historical uptime data.",[16,5027,5028,5029],{},"At its core, a statuspage answers one question: ",[26,5030,5031],{},"Is the service working right now?",[16,5033,5034],{},"Simple as that sounds, the implications are significant. Without a statuspage, users experiencing an outage have no choice but to contact support — via email, phone, or chat. The result: overwhelmed support teams, frustrated customers, and a loss of control over the narrative. With a well-maintained statuspage, incidents are communicated proactively before the first support ticket is filed.",[16,5036,5037],{},"Companies like GitHub, Cloudflare, and Stripe have operated public statuspages for years. But the concept is far from limited to large enterprises. Any organization that runs digital services — from early-stage SaaS startups to internal IT departments — benefits from a transparent statuspage.",[11,5039,5041],{"id":5040},"who-needs-a-statuspage","Who Needs a Statuspage?",[65,5043,5045],{"id":5044},"saas-companies-and-software-providers","SaaS Companies and Software Providers",[16,5047,5048],{},"For SaaS companies, a statuspage is not optional. Customers pay for availability. When a service goes down and the provider stays silent, uncertainty takes over. A statuspage communicates: We are aware, we are working on it, and we will keep you updated. That is the difference between a professional vendor and one that cannot be trusted.",[65,5050,5052],{"id":5051},"hosting-providers-and-infrastructure-companies","Hosting Providers and Infrastructure Companies",[16,5054,5055],{},"Hosting providers operate at a layer where outages cascade. When a data center has issues, hundreds of customers are potentially affected. A statuspage with granular breakdowns by region, service, and system is essential at this scale.",[65,5057,5059],{"id":5058},"e-commerce-and-online-retail","E-Commerce and Online Retail",[16,5061,5062],{},"In e-commerce, downtime means direct revenue loss. A statuspage informs not just end customers but also payment processors, logistics partners, and internal teams. During peak seasons — Black Friday, holiday shopping — proactive status communication becomes business-critical.",[65,5064,5066],{"id":5065},"internal-it-teams","Internal IT Teams",[16,5068,5069],{},"Not every statuspage needs to be public. Internal statuspages inform employees about the status of corporate systems: ERP, CRM, email, VPN, internal tools. This reduces internal support tickets and gives the IT department room to focus on resolution rather than communication.",[65,5071,5073],{"id":5072},"regulated-industries","Regulated Industries",[16,5075,5076],{},"Organizations in regulated industries — financial services, healthcare, government — often face compliance requirements around availability documentation and incident communication. A statuspage with a complete history and SLA tracking fulfills these requirements in a structured, auditable way.",[11,5078,5080],{"id":5079},"core-features-of-a-good-statuspage","Core Features of a Good Statuspage",[16,5082,5083],{},"Not all statuspages are created equal. The difference between a useful statuspage and a useless one comes down to features and execution.",[65,5085,5087],{"id":5086},"services-and-components","Services and Components",[16,5089,5090],{},"A statuspage should not display overall status as a single value. It should break down into logical services and components. A user relying on the API does not care about the dashboard status — and vice versa. Granularity creates relevance.",[65,5092,5094],{"id":5093},"real-time-status-display","Real-Time Status Display",[16,5096,5097],{},"The current status of each service must be visible at a glance. Common levels include: Operational, Degraded Performance, Partial Outage, and Major Outage. Color coding — green, yellow, orange, red — makes status intuitively readable without requiring users to parse text.",[65,5099,5101],{"id":5100},"incident-updates-with-timeline","Incident Updates with Timeline",[16,5103,5104],{},"During an incident, posting \"There is a problem\" once is not enough. Professional incident communication includes a complete timeline: detection, investigation, root cause identification, fix implementation, and resolution confirmation. Each step is documented with a timestamp.",[65,5106,5108],{"id":5107},"subscribers-and-notifications","Subscribers and Notifications",[16,5110,5111],{},"Not every user actively checks the statuspage. Subscriber functionality allows users to receive email notifications about incidents and maintenance. This is the difference between pull and push communication — and push wins in practice every time.",[65,5113,5115],{"id":5114},"scheduled-maintenance-windows","Scheduled Maintenance Windows",[16,5117,5118],{},"Maintenance is inevitable. A good statuspage allows teams to announce maintenance windows in advance, mark affected services, and notify subscribers ahead of time. This prevents unnecessary support tickets and demonstrates professional planning.",[65,5120,5122],{"id":5121},"uptime-history-and-sla-tracking","Uptime History and SLA Tracking",[16,5124,5125],{},"A statuspage without history is just a snapshot. Uptime history — ideally displayed as a calendar or timeline over 30, 60, or 90 days — gives users and prospective customers an overview of long-term reliability. For B2B buyers evaluating vendors, this is often a deciding factor.",[11,5127,5129],{"id":5128},"what-separates-a-good-statuspage-from-a-bad-one","What Separates a Good Statuspage from a Bad One?",[65,5131,5133],{"id":5132},"transparency-over-spin","Transparency Over Spin",[16,5135,5136],{},"The most common failure: statuspages that permanently display \"All Systems Operational\" while users are actively experiencing problems. A statuspage that hides or delays incident reports is worse than no statuspage at all. It actively erodes trust.",[16,5138,5139],{},"A good statuspage names problems clearly and promptly. It describes what is affected, what the impact is, and when a resolution is expected. Perfection is not the goal — honesty is.",[65,5141,5143],{"id":5142},"timeliness-and-speed","Timeliness and Speed",[16,5145,5146],{},"A statuspage that gets updated 30 minutes after an outage begins has missed its purpose. Updates should happen within minutes — ideally triggered automatically by the monitoring system that detected the issue.",[65,5148,5150],{"id":5149},"design-and-readability","Design and Readability",[16,5152,5153],{},"A statuspage must work at first glance. The user arrives with a specific question: Is my service running? The answer must be immediately visible — no scrolling, no searching, no interpretation required. Clean typography, consistent color coding, and a logical structure are non-negotiable.",[65,5155,5157],{"id":5156},"mobile-experience","Mobile Experience",[16,5159,5160],{},"Outages do not only happen during office hours. Users check status on their phones, on the go, in transit. A statuspage that performs poorly on mobile devices is practically unusable in real-world scenarios. Progressive Web App (PWA) support takes the mobile experience a step further, enabling home screen installation and offline access to the last known status.",[11,5162,5164],{"id":5163},"why-transparency-builds-trust","Why Transparency Builds Trust",[16,5166,5167],{},"Many companies hesitate to launch a public statuspage. The fear: if we make our outages public, we will lose customers. Reality consistently shows the opposite.",[65,5169,5171],{"id":5170},"outages-are-normal-silence-is-not","Outages Are Normal — Silence Is Not",[16,5173,5174],{},"Every service goes down eventually. Your customers know this. What customers will not accept is opacity. When a service is not working and the company stays silent, the trust damage extends far beyond the outage itself. Customers wonder: Do they even know there is a problem? Do they care?",[65,5176,5178],{"id":5177},"proactive-communication-reduces-support-load","Proactive Communication Reduces Support Load",[16,5180,5181],{},"Industry experience shows consistently that an actively maintained statuspage reduces support ticket volume during incidents by 30 to 50 percent. Instead of answering hundreds of identical tickets, a single statuspage entry directs all affected users to the same information.",[65,5183,5185],{"id":5184},"transparency-as-a-competitive-advantage","Transparency as a Competitive Advantage",[16,5187,5188],{},"In markets with many comparable providers, transparency becomes a differentiator. A vendor that openly displays uptime history signals confidence and professionalism. This matters especially for B2B buyers who evaluate vendors and want to assess reliability objectively.",[65,5190,5192],{"id":5191},"post-mortems-build-long-term-trust","Post-Mortems Build Long-Term Trust",[16,5194,5195],{},"The best organizations go a step further: after a major incident, they publish a detailed post-mortem. What happened? Why? What is being done to prevent recurrence? This level of openness builds more trust than a spotless uptime dashboard ever could.",[11,5197,5199],{"id":5198},"statuspage-vs-monitoring-why-you-need-both","Statuspage vs. Monitoring — Why You Need Both",[16,5201,5202],{},"A common mistake: monitoring and statuspages are treated as separate problems and solved with separate tools. In practice, this leads to friction, manual processes, and delayed updates.",[65,5204,5206],{"id":5205},"what-monitoring-does","What Monitoring Does",[16,5208,5209],{},"Monitoring watches the availability and performance of services. HTTP checks verify that a website is reachable. TCP checks test network services. Heartbeat checks monitor cron jobs and background processes. When a check fails, an alert is triggered.",[65,5211,5213],{"id":5212},"what-a-statuspage-does","What a Statuspage Does",[16,5215,5216],{},"A statuspage communicates status externally. It is the interface between the internal knowledge of an incident and the external communication to customers and stakeholders.",[65,5218,5220],{"id":5219},"the-gap-between-the-two","The Gap Between the Two",[16,5222,5223],{},"When monitoring and statuspage are separate systems, a gap emerges. Monitoring detects the outage, but the statuspage only gets updated manually — whenever someone remembers to do it. In the meantime — minutes or, in worst cases, hours — the statuspage falsely shows \"All Operational.\"",[16,5225,5226],{},"The solution is an integrated platform that combines monitoring and statuspage in one system. When a check fails, an incident is automatically created and the statuspage is updated. When the check recovers, the incident is automatically marked as resolved. No manual step, no delay.",[11,5228,5230],{"id":5229},"how-to-set-up-a-statuspage","How to Set Up a Statuspage",[65,5232,5234],{"id":5233},"step-1-define-your-services","Step 1: Define Your Services",[16,5236,5237],{},"Before the statuspage goes live, decide which services to display. A good structure follows the user perspective, not the internal architecture. Instead of \"PostgreSQL Primary\" and \"Redis Cluster,\" use: \"API,\" \"Dashboard,\" \"Email Delivery,\" \"Payments.\"",[65,5239,5241],{"id":5240},"step-2-set-up-monitoring","Step 2: Set Up Monitoring",[16,5243,5244],{},"Each service should have at least one monitoring check. HTTP checks for web applications, TCP checks for database connections, heartbeat checks for background processes. The checks must be representative — they should test exactly what the end user perceives as \"working\" or \"not working.\"",[65,5246,5248],{"id":5247},"step-3-define-your-incident-workflow","Step 3: Define Your Incident Workflow",[16,5250,5251],{},"Who can create incidents? Who writes updates? At what intervals are updates posted? These processes should be defined before the first outage occurs. A clear workflow with defined roles and escalation levels prevents chaos when it matters most.",[65,5253,5255],{"id":5254},"step-4-design-and-publish-the-statuspage","Step 4: Design and Publish the Statuspage",[16,5257,5258],{},"The design and branding of the statuspage should match the company. The statuspage is a customer touchpoint — it should look professional and reflect the brand identity. A subdomain (status.example.com) or custom domain are common approaches.",[65,5260,5262],{"id":5261},"step-5-enable-subscribers-and-spread-the-word","Step 5: Enable Subscribers and Spread the Word",[16,5264,5265],{},"After launch, customers need to know the statuspage exists. Links in the main website footer, documentation, onboarding emails, and support portal are standard placements. Subscriber options — email newsletter, RSS, webhooks — enable push notifications for those who want them.",[65,5267,5269],{"id":5268},"example-setting-up-a-statuspage-with-livck","Example: Setting Up a Statuspage with LIVCK",[16,5271,5272],{},"LIVCK is a monitoring and statuspage solution from Germany that combines both functions in a single platform. The setup process illustrates how an integrated approach works in practice:",[16,5274,5275,5278],{},[26,5276,5277],{},"Installation:"," LIVCK can be self-hosted via Docker Compose in minutes — on any server with Docker support. Alternatively, a managed service is available. A cloud option with a free starter plan is in the works.",[16,5280,5281,5284],{},[26,5282,5283],{},"Configure Monitoring:"," After installation, set up checks — HTTP(S) for web applications, TCP for network services, SSL for certificates, Heartbeat for cron jobs and scheduled tasks. Against false alarms, LIVCK checks from multiple independent locations — an incident is only triggered once the majority of probes confirm the outage.",[16,5286,5287,5290],{},[26,5288,5289],{},"Design the Statuspage:"," The drag-and-drop designer lets you build the statuspage visually. Three themes serve as starting points. Custom branding — logo, colors, domain — is included in every plan at no extra cost.",[16,5292,5293,5295],{},[26,5294,4068],{}," LIVCK uses a full incident workflow with Outage Linking. This means: when multiple services are affected by the same root cause, they are grouped into a single incident. Subscribers are automatically notified via email, Slack, Discord, Telegram, or SMS.",[16,5297,5298,5301],{},[26,5299,5300],{},"GDPR by Design:"," Since LIVCK can be self-hosted or runs in German data centers, all data stays under your control. For organizations with strict data privacy requirements or those operating in regulated industries, this is a decisive advantage over US-based providers.",[11,5303,5305],{"id":5304},"best-practices-for-ongoing-operations","Best Practices for Ongoing Operations",[16,5307,5308],{},"Setting up a statuspage is the first step. Operating it well over time is the real challenge.",[16,5310,5311,5314],{},[26,5312,5313],{},"Automate Where Possible:"," Manual statuspage updates are error-prone and slow. Every incident detected by monitoring should be automatically reflected on the statuspage without human intervention for the initial status change.",[16,5316,5317,5320],{},[26,5318,5319],{},"Communicate Maintenance Regularly:"," Even when there are no incidents, regular maintenance announcements show that the statuspage is actively maintained. A statuspage with no entries for months looks abandoned — and abandoned tools do not inspire confidence.",[16,5322,5323,5326],{},[26,5324,5325],{},"Use Clear Language:"," Incident updates should be written for end users, not for engineers. Instead of \"OOM kill on pod-xyz-123 in k8s cluster,\" write: \"Our dashboard is currently unavailable. We have identified the cause and are working on a fix. We expect to have this resolved within the next 30 minutes.\"",[16,5328,5329,5332],{},[26,5330,5331],{},"Grow Your Subscriber Base:"," The more users subscribed to the statuspage, the more effective incident communication becomes. Active prompts to subscribe during onboarding and in support interactions pay dividends over time.",[16,5334,5335,5338],{},[26,5336,5337],{},"Review and Improve:"," After every major incident, review how the statuspage communication went. Was the first update timely? Were updates frequent enough? Was the language clear? Continuous improvement of the incident communication process is just as important as improving the infrastructure itself.",[11,5340,772],{"id":771},[16,5342,5343],{},"A statuspage is not a nice-to-have — it is a core component of professional service operations. It reduces support load, builds trust through transparency, and gives customers confidence that incidents are detected and handled.",[16,5345,5346],{},"The greatest impact comes when the statuspage is integrated with the monitoring system. Separate tools for monitoring and statuspage create delays and manual overhead. An integrated approach — like LIVCK, which combines monitoring, incident management, and statuspage in a single platform — closes that gap entirely.",[16,5348,5349],{},"Whether public-facing for customers or internal for teams: anyone operating digital services needs a statuspage. Not as a marketing tool, but as an instrument for honest, timely communication. Because trust is not built through perfect uptime — it is built through the professional handling of the moments when things go wrong.",{"title":107,"searchDepth":121,"depth":121,"links":5351},[5352,5353,5360,5368,5374,5380,5385,5393,5394],{"id":1669,"depth":121,"text":5022},{"id":5040,"depth":121,"text":5041,"children":5354},[5355,5356,5357,5358,5359],{"id":5044,"depth":331,"text":5045},{"id":5051,"depth":331,"text":5052},{"id":5058,"depth":331,"text":5059},{"id":5065,"depth":331,"text":5066},{"id":5072,"depth":331,"text":5073},{"id":5079,"depth":121,"text":5080,"children":5361},[5362,5363,5364,5365,5366,5367],{"id":5086,"depth":331,"text":5087},{"id":5093,"depth":331,"text":5094},{"id":5100,"depth":331,"text":5101},{"id":5107,"depth":331,"text":5108},{"id":5114,"depth":331,"text":5115},{"id":5121,"depth":331,"text":5122},{"id":5128,"depth":121,"text":5129,"children":5369},[5370,5371,5372,5373],{"id":5132,"depth":331,"text":5133},{"id":5142,"depth":331,"text":5143},{"id":5149,"depth":331,"text":5150},{"id":5156,"depth":331,"text":5157},{"id":5163,"depth":121,"text":5164,"children":5375},[5376,5377,5378,5379],{"id":5170,"depth":331,"text":5171},{"id":5177,"depth":331,"text":5178},{"id":5184,"depth":331,"text":5185},{"id":5191,"depth":331,"text":5192},{"id":5198,"depth":121,"text":5199,"children":5381},[5382,5383,5384],{"id":5205,"depth":331,"text":5206},{"id":5212,"depth":331,"text":5213},{"id":5219,"depth":331,"text":5220},{"id":5229,"depth":121,"text":5230,"children":5386},[5387,5388,5389,5390,5391,5392],{"id":5233,"depth":331,"text":5234},{"id":5240,"depth":331,"text":5241},{"id":5247,"depth":331,"text":5248},{"id":5254,"depth":331,"text":5255},{"id":5261,"depth":331,"text":5262},{"id":5268,"depth":331,"text":5269},{"id":5304,"depth":121,"text":5305},{"id":771,"depth":121,"text":772},"Fundamentals","What is a statuspage, why do you need one, and what makes a good statuspage? Everything about features, use cases, and why transparency builds trust.",[5398,5399,5401,5403],{"question":5022,"answer":5025},{"question":5041,"answer":5400},"Any organization running digital services benefits: SaaS companies, hosting and infrastructure providers, e-commerce shops, internal IT teams, and regulated industries such as financial services, healthcare, and government. Internal statuspages also inform employees about the status of corporate systems like ERP, CRM, email, and VPN.",{"question":5129,"answer":5402},"A good statuspage names problems clearly and promptly instead of permanently showing All Systems Operational, updates within minutes — ideally triggered automatically by the monitoring system — and is readable at first glance and on mobile. A statuspage that hides or delays incident reports is worse than none, because it actively erodes trust.",{"question":5230,"answer":5404},"In five steps: define your services from the user perspective, set up at least one monitoring check per service (HTTP, TCP, heartbeat), define an incident workflow with roles and escalation levels, design and publish the statuspage, and enable subscribers while spreading the word.",{},"\u002Fguides\u002Fen\u002Fwhat-is-a-statuspage","was-ist-eine-statuspage",[1665,1666,1667],[2242,850],{"title":5017,"description":5396},"guides\u002Fen\u002Fwhat-is-a-statuspage","xziKDCNdJklhgCAHlV3BNgSAswcH6qkFGEX9AxCX3-8",1783478152366]