[{"data":1,"prerenderedAt":1782},["ShallowReactive",2],{"lang-switch-guide-/en/guides/statuspage-best-practices":3,"guide-/guides/en/statuspage-best-practices":5,"related-guides-en-what-is-a-statuspage-self-hosted-statuspage":564},{"peerSlug":4},"statuspage-best-practices",{"id":6,"title":7,"body":8,"category":546,"description":547,"extension":548,"meta":549,"navigation":550,"path":551,"peerSlug":4,"publishedAt":552,"readingTime":553,"relatedComparisons":554,"relatedGuides":558,"seo":561,"stem":562,"__hash__":563},"guides/guides/en/statuspage-best-practices.md","Statuspage Best Practices — Transparency, Design & Incident Communication",{"type":9,"value":10,"toc":486},"minimark",[11,16,20,23,26,29,33,36,41,44,48,51,55,58,62,65,69,76,82,88,94,100,106,112,118,124,127,130,134,138,141,163,167,170,174,177,198,201,205,208,212,215,218,222,225,229,232,236,239,243,246,250,258,262,265,268,272,275,279,282,286,289,292,296,299,303,306,310,313,317,320,324,327,331,334,338,358,361,365,369,372,376,379,383,386,390,394,397,401,404,408,411,415,418,422,425,429,432,436,439,443,446,450,453,457,460,480,483],[12,13,15],"h2",{"id":14},"why-a-well-run-statuspage-matters","Why a Well-Run Statuspage Matters",[17,18,19],"p",{},"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.",[17,21,22],{},"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.",[17,24,25],{},"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.",[17,27,28],{},"This guide covers the essential best practices that transform a statuspage from a forgotten subpage into a strategic communication tool.",[12,30,32],{"id":31},"transparent-communication-as-a-core-principle","Transparent Communication as a Core Principle",[17,34,35],{},"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.",[37,38,40],"h3",{"id":39},"proactive-over-reactive","Proactive Over Reactive",[17,42,43],{},"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.",[37,45,47],{"id":46},"plain-language-over-technical-jargon","Plain Language Over Technical Jargon",[17,49,50],{},"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.",[37,52,54],{"id":53},"no-finger-pointing","No Finger-Pointing",[17,56,57],{},"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.",[12,59,61],{"id":60},"using-status-levels-effectively","Using Status Levels Effectively",[17,63,64],{},"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.",[37,66,68],{"id":67},"the-5-stage-workflow-in-detail","The 5-Stage Workflow in Detail",[17,70,71,75],{},[72,73,74],"strong",{},"Investigating"," — 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.\"",[17,77,78,81],{},[72,79,80],{},"Identified"," — 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.\"",[17,83,84,87],{},[72,85,86],{},"Acknowledged"," — The problem is recognized and prioritized, but the fix requires time. Particularly relevant for issues that cannot be resolved immediately.",[17,89,90,93],{},[72,91,92],{},"In Progress"," — Active work on the fix. Users see that something is happening. \"The team is performing a rollback of the database schema changes.\"",[17,95,96,99],{},[72,97,98],{},"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.\"",[17,101,102,105],{},[72,103,104],{},"Under Review"," — Post-fix evaluation is underway. The incident is technically resolved, but the team is still checking for residual effects.",[17,107,108,111],{},[72,109,110],{},"Resolved"," — Everything is back to normal. Brief summary of what happened and what was done.",[17,113,114,117],{},[72,115,116],{},"Scheduled"," — For planned maintenance. Users are informed in advance.",[17,119,120,123],{},[72,121,122],{},"Closed"," — The incident is completed and archived.",[17,125,126],{},"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.",[17,128,129],{},"LIVCK implements this entire workflow natively. Every stage is built into the incident management system, including automatic notifications on status transitions.",[12,131,133],{"id":132},"incident-updates-frequency-tone-and-content","Incident Updates: Frequency, Tone, and Content",[37,135,137],{"id":136},"frequency","Frequency",[17,139,140],{},"During an active incident, the rule is: one update too many is better than one too few. A proven cadence:",[142,143,144,151,157],"ul",{},[145,146,147,150],"li",{},[72,148,149],{},"First 30 minutes:"," An update every 10 to 15 minutes, even if it only says \"Still investigating.\"",[145,152,153,156],{},[72,154,155],{},"After 30 minutes:"," Every 20 to 30 minutes, provided the status is changing.",[145,158,159,162],{},[72,160,161],{},"For extended incidents:"," At least once per hour. Users who see no updates assume that nobody is working on the problem.",[37,164,166],{"id":165},"tone","Tone",[17,168,169],{},"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.",[37,171,173],{"id":172},"content-of-a-good-update","Content of a Good Update",[17,175,176],{},"Every update should contain three elements:",[178,179,180,186,192],"ol",{},[145,181,182,185],{},[72,183,184],{},"Current state"," — What is happening right now?",[145,187,188,191],{},[72,189,190],{},"Next step"," — What is being done next?",[145,193,194,197],{},[72,195,196],{},"Expected timeline"," — When should users expect the next update?",[17,199,200],{},"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.\"",[12,202,204],{"id":203},"informing-subscribers-the-right-way","Informing Subscribers the Right Way",[17,206,207],{},"A statuspage that nobody visits serves no purpose. A functioning notification system is therefore essential.",[37,209,211],{"id":210},"think-multi-channel","Think Multi-Channel",[17,213,214],{},"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.",[17,216,217],{},"LIVCK natively supports email, Discord (webhook and bot), Slack, Telegram, SMS, and Pushover. All channels include throttling to prevent notification floods during major incidents.",[37,219,221],{"id":220},"newsletter-subscribers-vs-incident-subscribers","Newsletter Subscribers vs. Incident Subscribers",[17,223,224],{},"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.",[37,226,228],{"id":227},"using-announcements","Using Announcements",[17,230,231],{},"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.",[12,233,235],{"id":234},"design-and-branding-projecting-professionalism","Design and Branding: Projecting Professionalism",[17,237,238],{},"The statuspage is often the first touchpoint during a crisis. The standards for design and branding must reflect this.",[37,240,242],{"id":241},"consistent-branding","Consistent Branding",[17,244,245],{},"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.",[37,247,249],{"id":248},"custom-domain","Custom Domain",[17,251,252,253,257],{},"A statuspage at ",[254,255,256],"code",{},"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.",[37,259,261],{"id":260},"clarity-over-creativity","Clarity Over Creativity",[17,263,264],{},"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.",[17,266,267],{},"LIVCK offers three pre-built themes and a drag-and-drop designer for full customization. Custom branding, custom domains, and PWA support are included in every plan with no feature-gating.",[12,269,271],{"id":270},"monitoring-integration-why-monitoring-and-statuspage-belong-together","Monitoring Integration: Why Monitoring and Statuspage Belong Together",[17,273,274],{},"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.",[37,276,278],{"id":277},"automatic-detection-over-manual-reporting","Automatic Detection Over Manual Reporting",[17,280,281],{},"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.",[37,283,285],{"id":284},"outage-linking","Outage Linking",[17,287,288],{},"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.",[17,290,291],{},"LIVCK implements outage linking natively, connecting incidents with the services they affect without requiring manual intervention from the on-call engineer.",[37,293,295],{"id":294},"false-alarm-protection","False Alarm Protection",[17,297,298],{},"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 uses AMC (Automatic Misfire Correction) to detect and suppress false positives, preventing unnecessary noise on the statuspage and in notification channels.",[12,300,302],{"id":301},"communicating-maintenance-windows-professionally","Communicating Maintenance Windows Professionally",[17,304,305],{},"Planned maintenance is not an incident. It deserves its own communication strategy.",[37,307,309],{"id":308},"lead-time","Lead Time",[17,311,312],{},"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.",[37,314,316],{"id":315},"maintenance-windows-with-start-and-end-times","Maintenance Windows with Start and End Times",[17,318,319],{},"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.",[37,321,323],{"id":322},"status-during-maintenance","Status During Maintenance",[17,325,326],{},"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.",[12,328,330],{"id":329},"private-statuspages-for-internal-teams","Private Statuspages for Internal Teams",[17,332,333],{},"Not every statuspage is public. Internal statuspages for DevOps teams, management, or partners provide a protected communication channel with more technical detail.",[37,335,337],{"id":336},"use-cases","Use Cases",[142,339,340,346,352],{},[145,341,342,345],{},[72,343,344],{},"Internal infrastructure:"," Databases, message queues, internal APIs that end users never interact with directly.",[145,347,348,351],{},[72,349,350],{},"Partner integrations:"," Status overview for B2B partners who depend on your API.",[145,353,354,357],{},[72,355,356],{},"Regulated industries:"," Financial services, healthcare, or public sector organizations where certain information must not be publicly accessible.",[17,359,360],{},"Private pages with access control are included in every LIVCK plan. Teams can operate multiple statuspages for different audiences without needing separate tools.",[12,362,364],{"id":363},"uptime-metrics-and-sla-transparency","Uptime Metrics and SLA Transparency",[37,366,368],{"id":367},"uptime-calendar","Uptime Calendar",[17,370,371],{},"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.",[37,373,375],{"id":374},"sla-tracking","SLA Tracking",[17,377,378],{},"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.",[37,380,382],{"id":381},"badges","Badges",[17,384,385],{},"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.",[12,387,389],{"id":388},"common-mistakes-and-how-to-avoid-them","Common Mistakes and How to Avoid Them",[37,391,393],{"id":392},"mistake-1-only-updating-the-statuspage-during-major-outages","Mistake 1: Only Updating the Statuspage During Major Outages",[17,395,396],{},"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.",[37,398,400],{"id":399},"mistake-2-communicating-too-late","Mistake 2: Communicating Too Late",[17,402,403],{},"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.\"",[37,405,407],{"id":406},"mistake-3-no-post-mortem-after-major-incidents","Mistake 3: No Post-Mortem After Major Incidents",[17,409,410],{},"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.",[37,412,414],{"id":413},"mistake-4-running-monitoring-and-statuspage-as-separate-systems","Mistake 4: Running Monitoring and Statuspage as Separate Systems",[17,416,417],{},"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.",[37,419,421],{"id":420},"mistake-5-generic-design-with-no-brand-identity","Mistake 5: Generic Design With No Brand Identity",[17,423,424],{},"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.",[12,426,428],{"id":427},"building-a-statuspage-culture","Building a Statuspage Culture",[17,430,431],{},"Technical implementation is only half the equation. The other half is organizational discipline.",[37,433,435],{"id":434},"define-clear-ownership","Define Clear Ownership",[17,437,438],{},"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.",[37,440,442],{"id":441},"create-templates","Create Templates",[17,444,445],{},"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.",[37,447,449],{"id":448},"review-and-iterate","Review and Iterate",[17,451,452],{},"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.",[12,454,456],{"id":455},"conclusion","Conclusion",[17,458,459],{},"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:",[178,461,462,468,474],{},[145,463,464,467],{},[72,465,466],{},"Transparency:"," Communicate early, communicate honestly, communicate regularly.",[145,469,470,473],{},[72,471,472],{},"Structure:"," Clear status levels, defined processes, consistent updates.",[145,475,476,479],{},[72,477,478],{},"Integration:"," Monitoring and statuspage belong together. Manual processes lead to delays and errors.",[17,481,482],{},"LIVCK combines monitoring and statuspage in a single solution, with a 5-stage incident workflow, outage linking, 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.",[17,484,485],{},"Organizations that commit to these best practices transform their statuspage from a technical obligation into a genuine competitive advantage.",{"title":487,"searchDepth":488,"depth":488,"links":489},"",2,[490,491,497,500,505,510,515,520,525,528,533,540,545],{"id":14,"depth":488,"text":15},{"id":31,"depth":488,"text":32,"children":492},[493,495,496],{"id":39,"depth":494,"text":40},3,{"id":46,"depth":494,"text":47},{"id":53,"depth":494,"text":54},{"id":60,"depth":488,"text":61,"children":498},[499],{"id":67,"depth":494,"text":68},{"id":132,"depth":488,"text":133,"children":501},[502,503,504],{"id":136,"depth":494,"text":137},{"id":165,"depth":494,"text":166},{"id":172,"depth":494,"text":173},{"id":203,"depth":488,"text":204,"children":506},[507,508,509],{"id":210,"depth":494,"text":211},{"id":220,"depth":494,"text":221},{"id":227,"depth":494,"text":228},{"id":234,"depth":488,"text":235,"children":511},[512,513,514],{"id":241,"depth":494,"text":242},{"id":248,"depth":494,"text":249},{"id":260,"depth":494,"text":261},{"id":270,"depth":488,"text":271,"children":516},[517,518,519],{"id":277,"depth":494,"text":278},{"id":284,"depth":494,"text":285},{"id":294,"depth":494,"text":295},{"id":301,"depth":488,"text":302,"children":521},[522,523,524],{"id":308,"depth":494,"text":309},{"id":315,"depth":494,"text":316},{"id":322,"depth":494,"text":323},{"id":329,"depth":488,"text":330,"children":526},[527],{"id":336,"depth":494,"text":337},{"id":363,"depth":488,"text":364,"children":529},[530,531,532],{"id":367,"depth":494,"text":368},{"id":374,"depth":494,"text":375},{"id":381,"depth":494,"text":382},{"id":388,"depth":488,"text":389,"children":534},[535,536,537,538,539],{"id":392,"depth":494,"text":393},{"id":399,"depth":494,"text":400},{"id":406,"depth":494,"text":407},{"id":413,"depth":494,"text":414},{"id":420,"depth":494,"text":421},{"id":427,"depth":488,"text":428,"children":541},[542,543,544],{"id":434,"depth":494,"text":435},{"id":441,"depth":494,"text":442},{"id":448,"depth":494,"text":449},{"id":455,"depth":488,"text":456},"Best Practices","The most important best practices for statuspages: transparent communication, proper incident management, professional design and monitoring integration.","md",{},true,"/guides/en/statuspage-best-practices","2026-02-25",11,[555,556,557],"atlassian","instatus","hyperping",[559,560],"what-is-a-statuspage","self-hosted-statuspage",{"title":7,"description":547},"guides/en/statuspage-best-practices","Q9JQjmW7_VqBnWkZ7YJIKROeWlEogHvSLUgGFxwxYPo",[565,1391],{"id":566,"title":567,"body":568,"category":1380,"description":1381,"extension":548,"meta":1382,"navigation":550,"path":1383,"peerSlug":560,"publishedAt":552,"readingTime":553,"relatedComparisons":1384,"relatedGuides":1386,"seo":1388,"stem":1389,"__hash__":1390},"guides/guides/en/self-hosted-statuspage.md","Self-Hosted Statuspage — Why, How and Which Solution?",{"type":9,"value":569,"toc":1348},[570,574,577,580,583,587,590,594,597,601,604,630,634,637,641,644,648,651,655,658,662,665,669,672,676,679,682,716,719,723,726,804,807,810,814,817,821,826,829,867,872,923,928,931,945,948,952,996,999,1003,1006,1010,1013,1018,1038,1041,1045,1048,1054,1058,1189,1193,1196,1200,1203,1206,1209,1212,1216,1258,1261,1264,1267,1271,1274,1277,1280,1300,1303,1307,1310,1313,1316,1330,1332,1335,1338,1341,1344],[12,571,573],{"id":572},"why-self-hosting-your-statuspage-matters","Why Self-Hosting Your Statuspage Matters",[17,575,576],{},"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.",[17,578,579],{},"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.",[17,581,582],{},"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.",[12,584,586],{"id":585},"cloud-vs-self-hosted-an-honest-comparison","Cloud vs. Self-Hosted: An Honest Comparison",[17,588,589],{},"Both approaches have their place. The right choice depends on your specific requirements.",[37,591,593],{"id":592},"benefits-of-cloud-statuspages","Benefits of Cloud Statuspages",[17,595,596],{},"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.",[37,598,600],{"id":599},"benefits-of-self-hosted-statuspages","Benefits of Self-Hosted Statuspages",[17,602,603],{},"Self-hosting becomes relevant when one or more of the following criteria apply:",[142,605,606,612,618,624],{},[145,607,608,611],{},[72,609,610],{},"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.",[145,613,614,617],{},[72,615,616],{},"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.",[145,619,620,623],{},[72,621,622],{},"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.",[145,625,626,629],{},[72,627,628],{},"Customizability:"," Full control over domains, SSL certificates, network routing and integration into existing infrastructure.",[37,631,633],{"id":632},"drawbacks-of-self-hosting","Drawbacks of Self-Hosting",[17,635,636],{},"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.",[12,638,640],{"id":639},"regulated-industries-where-self-hosting-becomes-mandatory","Regulated Industries: Where Self-Hosting Becomes Mandatory",[17,642,643],{},"In certain industries, the question \"cloud or self-hosted?\" is not a technical preference but a regulatory decision.",[37,645,647],{"id":646},"data-centers-and-hosting-providers","Data Centers and Hosting Providers",[17,649,650],{},"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.\"",[37,652,654],{"id":653},"financial-services","Financial Services",[17,656,657],{},"Financial institutions subject to regulations like MaRisk (Germany), FCA (UK), SEC/FINRA (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.",[37,659,661],{"id":660},"healthcare","Healthcare",[17,663,664],{},"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.",[37,666,668],{"id":667},"government-and-public-sector","Government and Public Sector",[17,670,671],{},"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.",[12,673,675],{"id":674},"docker-as-the-standard-for-self-hosted-software","Docker as the Standard for Self-Hosted Software",[17,677,678],{},"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.",[17,680,681],{},"For statuspages, Docker is particularly sensible:",[142,683,684,690,696,710],{},[145,685,686,689],{},[72,687,688],{},"Isolation:"," The statuspage runs isolated from the rest of the system. Conflicts with other applications are impossible.",[145,691,692,695],{},[72,693,694],{},"Reproducibility:"," The same Docker image runs on a Hetzner server the same way it runs on AWS or in your own data center.",[145,697,698,701,702,705,706,709],{},[72,699,700],{},"Updates:"," New versions are shipped as a new image. An update consists of ",[254,703,704],{},"docker compose pull"," and ",[254,707,708],{},"docker compose up -d",".",[145,711,712,715],{},[72,713,714],{},"Rollbacks:"," If an update causes issues, you can revert to the previous version in seconds.",[17,717,718],{},"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.",[12,720,722],{"id":721},"server-requirements-what-do-you-actually-need","Server Requirements: What Do You Actually Need?",[17,724,725],{},"A self-hosted statuspage is not a resource-hungry application. The requirements are modest:",[727,728,729,745],"table",{},[730,731,732],"thead",{},[733,734,735,739,742],"tr",{},[736,737,738],"th",{},"Resource",[736,740,741],{},"Minimum",[736,743,744],{},"Recommended",[746,747,748,760,771,782,793],"tbody",{},[733,749,750,754,757],{},[751,752,753],"td",{},"CPU",[751,755,756],{},"1 vCPU",[751,758,759],{},"2 vCPU",[733,761,762,765,768],{},[751,763,764],{},"RAM",[751,766,767],{},"2 GB",[751,769,770],{},"4 GB",[733,772,773,776,779],{},[751,774,775],{},"Storage",[751,777,778],{},"20 GB SSD",[751,780,781],{},"40 GB SSD",[733,783,784,787,790],{},[751,785,786],{},"OS",[751,788,789],{},"Linux with Docker support",[751,791,792],{},"Ubuntu 22.04+ / Debian 12+",[733,794,795,798,801],{},[751,796,797],{},"Network",[751,799,800],{},"Public IP, port 80/443",[751,802,803],{},"Static IP, DDoS protection",[17,805,806],{},"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.",[17,808,809],{},"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.",[12,811,813],{"id":812},"setting-up-a-self-hosted-statuspage-with-livck","Setting Up a Self-Hosted Statuspage With LIVCK",[17,815,816],{},"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.",[37,818,820],{"id":819},"installation-in-three-steps","Installation in Three Steps",[17,822,823],{},[72,824,825],{},"Step 1: Prepare your server",[17,827,828],{},"On a fresh Linux server with Docker and Docker Compose:",[830,831,835],"pre",{"className":832,"code":833,"language":834,"meta":487,"style":487},"language-bash shiki shiki-themes github-light github-dark","# Install Docker (if not already present)\ncurl -fsSL https://get.docker.com | sh\n","bash",[254,836,837,846],{"__ignoreMap":487},[838,839,842],"span",{"class":840,"line":841},"line",1,[838,843,845],{"class":844},"sJ8bj","# Install Docker (if not already present)\n",[838,847,848,852,856,860,864],{"class":840,"line":488},[838,849,851],{"class":850},"sScJk","curl",[838,853,855],{"class":854},"sj4cs"," -fsSL",[838,857,859],{"class":858},"sZZnC"," https://get.docker.com",[838,861,863],{"class":862},"szBVR"," |",[838,865,866],{"class":850}," sh\n",[17,868,869],{},[72,870,871],{},"Step 2: Deploy LIVCK",[830,873,875],{"className":832,"code":874,"language":834,"meta":487,"style":487},"# Download the LIVCK Docker Compose file\ncurl -fsSL https://get.livck.com -o docker-compose.yml\n\n# Start LIVCK\ndocker compose up -d\n",[254,876,877,882,897,902,908],{"__ignoreMap":487},[838,878,879],{"class":840,"line":841},[838,880,881],{"class":844},"# Download the LIVCK Docker Compose file\n",[838,883,884,886,888,891,894],{"class":840,"line":488},[838,885,851],{"class":850},[838,887,855],{"class":854},[838,889,890],{"class":858}," https://get.livck.com",[838,892,893],{"class":854}," -o",[838,895,896],{"class":858}," docker-compose.yml\n",[838,898,899],{"class":840,"line":494},[838,900,901],{"emptyLinePlaceholder":550},"\n",[838,903,905],{"class":840,"line":904},4,[838,906,907],{"class":844},"# Start LIVCK\n",[838,909,911,914,917,920],{"class":840,"line":910},5,[838,912,913],{"class":850},"docker",[838,915,916],{"class":858}," compose",[838,918,919],{"class":858}," up",[838,921,922],{"class":854}," -d\n",[17,924,925],{},[72,926,927],{},"Step 3: Configure your statuspage",[17,929,930],{},"After startup, LIVCK is accessible via the server's IP address. The setup wizard guides you through:",[142,932,933,936,939,942],{},[145,934,935],{},"Account and team creation",[145,937,938],{},"First statuspage configuration (theme, domain, branding)",[145,940,941],{},"Monitoring checks for your services",[145,943,944],{},"Notification integrations (email, Slack, Discord, Telegram, SMS)",[17,946,947],{},"The entire process typically takes under five minutes from an empty server to a functioning statuspage.",[37,949,951],{"id":950},"what-livck-provides-in-self-hosted-mode","What LIVCK Provides in Self-Hosted Mode",[142,953,954,960,966,972,978,984,990],{},[145,955,956,959],{},[72,957,958],{},"Monitoring:"," HTTP(S), TCP, Heartbeat and Manual checks with configurable intervals",[145,961,962,965],{},[72,963,964],{},"Statuspage:"," Three themes, visual designer, custom branding, multi-language support, PWA",[145,967,968,971],{},[72,969,970],{},"Incident Management:"," Five status stages, outage linking, announcements, maintenance windows",[145,973,974,977],{},[72,975,976],{},"Notifications:"," Email, Slack, Discord, Telegram, SMS, Pushover with throttling",[145,979,980,983],{},[72,981,982],{},"API:"," Public & Private API for automation and integration",[145,985,986,989],{},[72,987,988],{},"Team:"," Multiple members per plan, granular permissions, two-factor authentication",[145,991,992,995],{},[72,993,994],{},"Auto-Updater:"," LIVCK updates itself automatically without manual intervention",[17,997,998],{},"Crucially, all features are available in every plan. There is no feature-gating where basic functionality is locked behind more expensive tiers.",[12,1000,1002],{"id":1001},"comparison-with-open-source-alternatives","Comparison With Open-Source Alternatives",[17,1004,1005],{},"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.",[37,1007,1009],{"id":1008},"uptime-kuma","Uptime Kuma",[17,1011,1012],{},"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.",[17,1014,1015],{},[72,1016,1017],{},"Limitations:",[142,1019,1020,1023,1026,1029,1032,1035],{},[145,1021,1022],{},"The statuspage is minimal: no custom branding, no visual designer, no themes",[145,1024,1025],{},"No real incident management (no status stages, no outage linking)",[145,1027,1028],{},"No subscriber notifications (users cannot subscribe to status updates)",[145,1030,1031],{},"No API for the statuspage itself",[145,1033,1034],{},"Single-user application — no team features, no role-based permissions",[145,1036,1037],{},"No professional support or SLA",[17,1039,1040],{},"Uptime Kuma excels as a personal monitoring dashboard. As a public-facing statuspage for an organization, it lacks essential functionality.",[37,1042,1044],{"id":1043},"cachethq","CachetHQ",[17,1046,1047],{},"CachetHQ was the most well-known open-source statuspage project. It offered a solid statuspage with incident tracking and subscriber management.",[17,1049,1050,1053],{},[72,1051,1052],{},"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.",[37,1055,1057],{"id":1056},"livck-in-comparison","LIVCK in Comparison",[727,1059,1060,1074],{},[730,1061,1062],{},[733,1063,1064,1067,1069,1071],{},[736,1065,1066],{},"Feature",[736,1068,1009],{},[736,1070,1044],{},[736,1072,1073],{},"LIVCK",[746,1075,1076,1089,1103,1116,1128,1141,1153,1164,1175],{},[733,1077,1078,1081,1084,1087],{},[751,1079,1080],{},"Monitoring",[751,1082,1083],{},"Yes",[751,1085,1086],{},"No",[751,1088,1083],{},[733,1090,1091,1094,1097,1100],{},[751,1092,1093],{},"Statuspage",[751,1095,1096],{},"Basic",[751,1098,1099],{},"Yes (outdated)",[751,1101,1102],{},"Yes (3 themes, designer)",[733,1104,1105,1108,1110,1113],{},[751,1106,1107],{},"Incident Management",[751,1109,1086],{},[751,1111,1112],{},"Simple",[751,1114,1115],{},"Yes (5 stages, linking)",[733,1117,1118,1121,1123,1125],{},[751,1119,1120],{},"Subscriber System",[751,1122,1086],{},[751,1124,1083],{},[751,1126,1127],{},"Yes (newsletter, PWA)",[733,1129,1130,1133,1135,1138],{},[751,1131,1132],{},"Team Features",[751,1134,1086],{},[751,1136,1137],{},"Limited",[751,1139,1140],{},"Yes (members per plan, roles)",[733,1142,1143,1146,1148,1150],{},[751,1144,1145],{},"API",[751,1147,1137],{},[751,1149,1083],{},[751,1151,1152],{},"Public & Private API",[733,1154,1155,1158,1160,1162],{},[751,1156,1157],{},"Auto-Updater",[751,1159,1086],{},[751,1161,1086],{},[751,1163,1083],{},[733,1165,1166,1169,1171,1173],{},[751,1167,1168],{},"Actively Maintained",[751,1170,1083],{},[751,1172,1086],{},[751,1174,1083],{},[733,1176,1177,1180,1183,1186],{},[751,1178,1179],{},"Support",[751,1181,1182],{},"Community",[751,1184,1185],{},"None",[751,1187,1188],{},"Professional",[12,1190,1192],{"id":1191},"cost-analysis-self-hosted-vs-cloud-providers","Cost Analysis: Self-Hosted vs. Cloud Providers",[17,1194,1195],{},"An honest cost comparison reveals why self-hosting is economically compelling.",[37,1197,1199],{"id":1198},"cloud-providers-typical-costs","Cloud Providers: Typical Costs",[17,1201,1202],{},"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.",[17,1204,1205],{},"Better Stack starts free, but usable plans with sufficient monitors and statuspage features quickly reach USD 80 to 150 per month.",[17,1207,1208],{},"Instatus offers a lower entry point at USD 20 with basic monitoring, but advanced features cost up to USD 300 per month.",[17,1210,1211],{},"For international teams, these USD-denominated prices also carry currency risk and often increase at renewal.",[37,1213,1215],{"id":1214},"self-hosted-with-livck-total-cost","Self-Hosted With LIVCK: Total Cost",[727,1217,1218,1228],{},[730,1219,1220],{},[733,1221,1222,1225],{},[736,1223,1224],{},"Item",[736,1226,1227],{},"Cost per Month",[746,1229,1230,1238,1246],{},[733,1231,1232,1235],{},[751,1233,1234],{},"Server (Hetzner Cloud, CX22)",[751,1236,1237],{},"EUR 4.75",[733,1239,1240,1243],{},[751,1241,1242],{},"LIVCK Starter license",[751,1244,1245],{},"EUR 9.90",[733,1247,1248,1253],{},[751,1249,1250],{},[72,1251,1252],{},"Total",[751,1254,1255],{},[72,1256,1257],{},"EUR 14.65",[17,1259,1260],{},"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.",[17,1262,1263],{},"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.",[17,1265,1266],{},"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.",[12,1268,1270],{"id":1269},"auto-updates-and-maintenance","Auto-Updates and Maintenance",[17,1272,1273],{},"A common argument against self-hosting is the maintenance overhead. With LIVCK, this overhead is minimal.",[17,1275,1276],{},"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.",[17,1278,1279],{},"For the server itself, recommended practices include:",[142,1281,1282,1288,1294],{},[145,1283,1284,1287],{},[72,1285,1286],{},"Unattended upgrades"," for the operating system",[145,1289,1290,1293],{},[72,1291,1292],{},"Regular backups"," of the database (cron job, daily export)",[145,1295,1296,1299],{},[72,1297,1298],{},"Monitoring the server itself"," — ideally from an external location",[17,1301,1302],{},"The actual time investment for maintaining a self-hosted LIVCK instance is a few minutes per month when the auto-updater is active.",[12,1304,1306],{"id":1305},"managed-service-the-middle-ground","Managed Service: The Middle Ground",[17,1308,1309],{},"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.",[17,1311,1312],{},"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.",[17,1314,1315],{},"This is particularly relevant for:",[142,1317,1318,1321,1324,1327],{},[145,1319,1320],{},"Organizations without a dedicated DevOps team",[145,1322,1323],{},"Companies that need to demonstrate GDPR compliance but do not operate internal hosting",[145,1325,1326],{},"Teams that want to start quickly and take over server administration later",[145,1328,1329],{},"International organizations that need EU-based data processing for regulatory reasons",[12,1331,456],{"id":455},[17,1333,1334],{},"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.",[17,1336,1337],{},"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.",[17,1339,1340],{},"LIVCK provides monitoring and statuspage functionality from a single tool, built in Germany: self-hosted via Docker Compose, optionally as a managed service, with a cloud variant coming soon. All features in every plan, automatic updates, professional support.",[17,1342,1343],{},"If your statuspage is critical to your operations — and it should be — the control over it should remain in your hands.",[1345,1346,1347],"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 .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":487,"searchDepth":488,"depth":488,"links":1349},[1350,1351,1356,1362,1363,1364,1368,1373,1377,1378,1379],{"id":572,"depth":488,"text":573},{"id":585,"depth":488,"text":586,"children":1352},[1353,1354,1355],{"id":592,"depth":494,"text":593},{"id":599,"depth":494,"text":600},{"id":632,"depth":494,"text":633},{"id":639,"depth":488,"text":640,"children":1357},[1358,1359,1360,1361],{"id":646,"depth":494,"text":647},{"id":653,"depth":494,"text":654},{"id":660,"depth":494,"text":661},{"id":667,"depth":494,"text":668},{"id":674,"depth":488,"text":675},{"id":721,"depth":488,"text":722},{"id":812,"depth":488,"text":813,"children":1365},[1366,1367],{"id":819,"depth":494,"text":820},{"id":950,"depth":494,"text":951},{"id":1001,"depth":488,"text":1002,"children":1369},[1370,1371,1372],{"id":1008,"depth":494,"text":1009},{"id":1043,"depth":494,"text":1044},{"id":1056,"depth":494,"text":1057},{"id":1191,"depth":488,"text":1192,"children":1374},[1375,1376],{"id":1198,"depth":494,"text":1199},{"id":1214,"depth":494,"text":1215},{"id":1269,"depth":488,"text":1270},{"id":1305,"depth":488,"text":1306},{"id":455,"depth":488,"text":456},"Self-Hosting","Self-hosted vs. cloud statuspage: benefits, requirements, Docker setup and comparison with open-source alternatives like Uptime Kuma and CachetHQ.",{},"/guides/en/self-hosted-statuspage",[1008,555,1385],"better-stack",[1387,559],"gdpr-statuspage",{"title":567,"description":1381},"guides/en/self-hosted-statuspage","DdvBYFcjNEUvr-elkgVPeKeaPvolTIV6T3VIQ62cgBU",{"id":1392,"title":1393,"body":1394,"category":1771,"description":1772,"extension":548,"meta":1773,"navigation":550,"path":1774,"peerSlug":1775,"publishedAt":552,"readingTime":1776,"relatedComparisons":1777,"relatedGuides":1778,"seo":1779,"stem":1780,"__hash__":1781},"guides/guides/en/what-is-a-statuspage.md","What Is a Statuspage? — Definition, Benefits & Best Practices",{"type":9,"value":1395,"toc":1726},[1396,1399,1402,1408,1411,1414,1418,1422,1425,1429,1432,1436,1439,1443,1446,1450,1453,1457,1460,1464,1467,1471,1474,1478,1481,1485,1488,1492,1495,1499,1502,1506,1510,1513,1516,1520,1523,1527,1530,1534,1537,1541,1544,1548,1551,1555,1558,1562,1565,1569,1572,1576,1579,1583,1586,1590,1593,1597,1600,1603,1607,1611,1614,1618,1621,1625,1628,1632,1635,1639,1642,1646,1649,1655,1661,1667,1672,1678,1682,1685,1691,1697,1703,1709,1715,1717,1720,1723],[12,1397,1398],{"id":559},"What Is a Statuspage?",[17,1400,1401],{},"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.",[17,1403,1404,1405],{},"At its core, a statuspage answers one question: ",[72,1406,1407],{},"Is the service working right now?",[17,1409,1410],{},"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.",[17,1412,1413],{},"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.",[12,1415,1417],{"id":1416},"who-needs-a-statuspage","Who Needs a Statuspage?",[37,1419,1421],{"id":1420},"saas-companies-and-software-providers","SaaS Companies and Software Providers",[17,1423,1424],{},"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.",[37,1426,1428],{"id":1427},"hosting-providers-and-infrastructure-companies","Hosting Providers and Infrastructure Companies",[17,1430,1431],{},"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.",[37,1433,1435],{"id":1434},"e-commerce-and-online-retail","E-Commerce and Online Retail",[17,1437,1438],{},"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.",[37,1440,1442],{"id":1441},"internal-it-teams","Internal IT Teams",[17,1444,1445],{},"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.",[37,1447,1449],{"id":1448},"regulated-industries","Regulated Industries",[17,1451,1452],{},"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.",[12,1454,1456],{"id":1455},"core-features-of-a-good-statuspage","Core Features of a Good Statuspage",[17,1458,1459],{},"Not all statuspages are created equal. The difference between a useful statuspage and a useless one comes down to features and execution.",[37,1461,1463],{"id":1462},"services-and-components","Services and Components",[17,1465,1466],{},"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.",[37,1468,1470],{"id":1469},"real-time-status-display","Real-Time Status Display",[17,1472,1473],{},"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.",[37,1475,1477],{"id":1476},"incident-updates-with-timeline","Incident Updates with Timeline",[17,1479,1480],{},"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.",[37,1482,1484],{"id":1483},"subscribers-and-notifications","Subscribers and Notifications",[17,1486,1487],{},"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.",[37,1489,1491],{"id":1490},"scheduled-maintenance-windows","Scheduled Maintenance Windows",[17,1493,1494],{},"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.",[37,1496,1498],{"id":1497},"uptime-history-and-sla-tracking","Uptime History and SLA Tracking",[17,1500,1501],{},"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.",[12,1503,1505],{"id":1504},"what-separates-a-good-statuspage-from-a-bad-one","What Separates a Good Statuspage from a Bad One?",[37,1507,1509],{"id":1508},"transparency-over-spin","Transparency Over Spin",[17,1511,1512],{},"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.",[17,1514,1515],{},"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.",[37,1517,1519],{"id":1518},"timeliness-and-speed","Timeliness and Speed",[17,1521,1522],{},"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.",[37,1524,1526],{"id":1525},"design-and-readability","Design and Readability",[17,1528,1529],{},"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.",[37,1531,1533],{"id":1532},"mobile-experience","Mobile Experience",[17,1535,1536],{},"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.",[12,1538,1540],{"id":1539},"why-transparency-builds-trust","Why Transparency Builds Trust",[17,1542,1543],{},"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.",[37,1545,1547],{"id":1546},"outages-are-normal-silence-is-not","Outages Are Normal — Silence Is Not",[17,1549,1550],{},"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?",[37,1552,1554],{"id":1553},"proactive-communication-reduces-support-load","Proactive Communication Reduces Support Load",[17,1556,1557],{},"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.",[37,1559,1561],{"id":1560},"transparency-as-a-competitive-advantage","Transparency as a Competitive Advantage",[17,1563,1564],{},"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.",[37,1566,1568],{"id":1567},"post-mortems-build-long-term-trust","Post-Mortems Build Long-Term Trust",[17,1570,1571],{},"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.",[12,1573,1575],{"id":1574},"statuspage-vs-monitoring-why-you-need-both","Statuspage vs. Monitoring — Why You Need Both",[17,1577,1578],{},"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.",[37,1580,1582],{"id":1581},"what-monitoring-does","What Monitoring Does",[17,1584,1585],{},"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.",[37,1587,1589],{"id":1588},"what-a-statuspage-does","What a Statuspage Does",[17,1591,1592],{},"A statuspage communicates status externally. It is the interface between the internal knowledge of an incident and the external communication to customers and stakeholders.",[37,1594,1596],{"id":1595},"the-gap-between-the-two","The Gap Between the Two",[17,1598,1599],{},"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.\"",[17,1601,1602],{},"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.",[12,1604,1606],{"id":1605},"how-to-set-up-a-statuspage","How to Set Up a Statuspage",[37,1608,1610],{"id":1609},"step-1-define-your-services","Step 1: Define Your Services",[17,1612,1613],{},"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.\"",[37,1615,1617],{"id":1616},"step-2-set-up-monitoring","Step 2: Set Up Monitoring",[17,1619,1620],{},"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.\"",[37,1622,1624],{"id":1623},"step-3-define-your-incident-workflow","Step 3: Define Your Incident Workflow",[17,1626,1627],{},"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.",[37,1629,1631],{"id":1630},"step-4-design-and-publish-the-statuspage","Step 4: Design and Publish the Statuspage",[17,1633,1634],{},"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.",[37,1636,1638],{"id":1637},"step-5-enable-subscribers-and-spread-the-word","Step 5: Enable Subscribers and Spread the Word",[17,1640,1641],{},"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.",[37,1643,1645],{"id":1644},"example-setting-up-a-statuspage-with-livck","Example: Setting Up a Statuspage with LIVCK",[17,1647,1648],{},"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:",[17,1650,1651,1654],{},[72,1652,1653],{},"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.",[17,1656,1657,1660],{},[72,1658,1659],{},"Configure Monitoring:"," After installation, set up checks — HTTP(S) for web applications, TCP for network services, Heartbeat for cron jobs and scheduled tasks. LIVCK includes AMC (Automatic Misfire Correction), a false alarm protection mechanism that only triggers an incident after confirmation from multiple check points.",[17,1662,1663,1666],{},[72,1664,1665],{},"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.",[17,1668,1669,1671],{},[72,1670,970],{}," LIVCK uses a 5-stage 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.",[17,1673,1674,1677],{},[72,1675,1676],{},"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.",[12,1679,1681],{"id":1680},"best-practices-for-ongoing-operations","Best Practices for Ongoing Operations",[17,1683,1684],{},"Setting up a statuspage is the first step. Operating it well over time is the real challenge.",[17,1686,1687,1690],{},[72,1688,1689],{},"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.",[17,1692,1693,1696],{},[72,1694,1695],{},"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.",[17,1698,1699,1702],{},[72,1700,1701],{},"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.\"",[17,1704,1705,1708],{},[72,1706,1707],{},"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.",[17,1710,1711,1714],{},[72,1712,1713],{},"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.",[12,1716,456],{"id":455},[17,1718,1719],{},"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.",[17,1721,1722],{},"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.",[17,1724,1725],{},"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":487,"searchDepth":488,"depth":488,"links":1727},[1728,1729,1736,1744,1750,1756,1761,1769,1770],{"id":559,"depth":488,"text":1398},{"id":1416,"depth":488,"text":1417,"children":1730},[1731,1732,1733,1734,1735],{"id":1420,"depth":494,"text":1421},{"id":1427,"depth":494,"text":1428},{"id":1434,"depth":494,"text":1435},{"id":1441,"depth":494,"text":1442},{"id":1448,"depth":494,"text":1449},{"id":1455,"depth":488,"text":1456,"children":1737},[1738,1739,1740,1741,1742,1743],{"id":1462,"depth":494,"text":1463},{"id":1469,"depth":494,"text":1470},{"id":1476,"depth":494,"text":1477},{"id":1483,"depth":494,"text":1484},{"id":1490,"depth":494,"text":1491},{"id":1497,"depth":494,"text":1498},{"id":1504,"depth":488,"text":1505,"children":1745},[1746,1747,1748,1749],{"id":1508,"depth":494,"text":1509},{"id":1518,"depth":494,"text":1519},{"id":1525,"depth":494,"text":1526},{"id":1532,"depth":494,"text":1533},{"id":1539,"depth":488,"text":1540,"children":1751},[1752,1753,1754,1755],{"id":1546,"depth":494,"text":1547},{"id":1553,"depth":494,"text":1554},{"id":1560,"depth":494,"text":1561},{"id":1567,"depth":494,"text":1568},{"id":1574,"depth":488,"text":1575,"children":1757},[1758,1759,1760],{"id":1581,"depth":494,"text":1582},{"id":1588,"depth":494,"text":1589},{"id":1595,"depth":494,"text":1596},{"id":1605,"depth":488,"text":1606,"children":1762},[1763,1764,1765,1766,1767,1768],{"id":1609,"depth":494,"text":1610},{"id":1616,"depth":494,"text":1617},{"id":1623,"depth":494,"text":1624},{"id":1630,"depth":494,"text":1631},{"id":1637,"depth":494,"text":1638},{"id":1644,"depth":494,"text":1645},{"id":1680,"depth":488,"text":1681},{"id":455,"depth":488,"text":456},"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.",{},"/guides/en/what-is-a-statuspage","was-ist-eine-statuspage",10,[555,1385,556],[4,560],{"title":1393,"description":1772},"guides/en/what-is-a-statuspage","_NE0cpsIGpI6CqhMv5RoVWNMzC0PzhfNdreiKocezL8",1772268900403]