Skip to content

RealUptime Guides

Practical guidance for honest infrastructure.

What to publish, what to say during an incident, and how checks work underneath the badge.

Status page best practicesWhat to publish, what order it belongs in, how granular your components should be, and how to stay honest when the truth is inconvenient.Incident communication: what to say and whenThe four-stage incident lifecycle, when to post the first update, how often to follow up, and copy-paste templates for each stage.Uptime monitoring explainedWhat a green badge actually measures, why single-location checks produce both false alarms and false confidence, and what multi-region checking fixes.What each monitoring status actually meansOperational, down, blocked, awaiting data, and not monitored from this region are five different facts. What each one claims, and why collapsing them into up or down throws information away.How Downdetector works, and when to trust itWhere crowd-reported outage data comes from, when a report spike is reliable, the four biases built into it, and how to compare sources during an incident before acting on one.47-day SSL certificates: what changes and whenCertificate lifetimes drop to 200 days in 2026, 100 in 2027 and 47 in 2029. The dates, what tends to break, and how to catch a failed renewal.Health check endpoints: what to returnShallow and deep checks, liveness and readiness, status codes, caching, and what a public health endpoint must never say.Postmortem template, blameless, with an exampleA free blameless postmortem template in Markdown, Confluence and Google Docs form, a filled example, and how to run the review.How to choose a status page toolA factual checklist: check granularity, alert honesty, incident workflow, subscriber notifications, pricing shape, and what to test before committing.Self-hosted Sentry requirementsThe documented hardware floor, how many containers the default install runs, the monthly upgrades and their hard stops, and when hosted error tracking is the simpler answer.GitHub Actions schedule not running? Catch missed runsWhy scheduled workflows start late, get dropped under load, or stop after 60 quiet days, and the two-line heartbeat step that turns a run that never happened into an alert.Watch your Uptime Kuma from outsideUptime Kuma cannot alert on its own outage. The one free outside check, HTTP or heartbeat, that tells you when Kuma, its host or your connection goes away.Crashlytics for web appsFirebase Crashlytics has never supported the browser. Why, and how teams on Firebase keep Crashlytics for mobile and send web errors somewhere that takes them.Error tracking for a Firebase web appStep by step: Sentry's open-source SDK on a Firebase Hosting site and its Cloud Functions, sending to RealUptime Errors, with source maps, CSP headers and alerts.NIS2 Article 23: telling your customersThe text of NIS2 Article 23 on notifying the recipients of your services and the 24-hour, 72-hour and one-month reports, mapped to the records a status page keeps.DORA Article 19: informing clients of incidentsDORA Articles 14, 19 and 28 and the time limits in Delegated Regulation 2025/301, mapped to the status page, monitoring and vendor records that support them.SOC 2 availability and vendor monitoring evidenceThe six Trust Services Criteria where monitoring produces the record (A1.1, A1.2, CC2.3, CC7.2, CC7.4, CC9.2), in the AICPA's words, and the exports that carry it.