[{"data":1,"prerenderedAt":406},["ShallowReactive",2],{"\u002Fblog\u002Fhow-to-set-up-a-status-page":3},{"id":4,"title":5,"author":6,"body":8,"category":394,"date":395,"description":396,"extension":397,"image":398,"lastUpdated":398,"meta":399,"navigation":400,"path":401,"readingTime":402,"seo":403,"stem":404,"__hash__":405},"blog\u002Fblog\u002Fhow-to-set-up-a-status-page.md","How to Set Up a Status Page (And What to Put on It)",{"name":7},"Vantaj Team",{"type":9,"value":10,"toc":368},"minimark",[11,19,22,27,30,33,36,40,45,48,51,73,76,102,105,109,112,126,129,133,136,140,143,147,150,154,159,170,173,178,184,187,192,198,201,205,208,214,217,221,228,240,243,247,250,256,262,265,268,272,278,284,290,296,300,323,326,329,333,337,340,344,347,351,354,358,361,365],[12,13,14,18],"p",{},[15,16,17],"strong",{},"A status page"," is a public web page that displays the current operational status of a service and its history of past incidents. When something goes wrong, customers check the status page instead of filing a support ticket. When everything is fine, the status page builds trust by showing a track record of reliability.",[12,20,21],{},"Companies like GitHub, Stripe, and Cloudflare maintain public status pages because they reduce support load during incidents and give customers a single place to track outages in real time.",[23,24,26],"h2",{"id":25},"why-a-status-page-reduces-the-damage-from-outages","Why a Status Page Reduces the Damage from Outages",[12,28,29],{},"When your service goes down without a status page, customers do two things: they file support tickets and they post on social media. Your support team gets overwhelmed at exactly the moment they're least available. Engineers get interrupted by Slack messages asking for updates instead of fixing the problem.",[12,31,32],{},"A status page with a live incident and regular updates costs your team 10 minutes to maintain. The alternative is 50 support tickets saying \"is it down for anyone else?\"",[12,34,35],{},"According to a 2024 Atlassian incident management survey, teams with public status pages handle 35–60% fewer duplicate support tickets during outages compared to teams without one. The page absorbs the question before it reaches your team.",[23,37,39],{"id":38},"what-to-include-on-a-status-page","What to Include on a Status Page",[41,42,44],"h3",{"id":43},"current-status-per-component","Current Status per Component",[12,46,47],{},"Break your service into logical components and display the status of each independently. This tells customers exactly what is broken and what still works.",[12,49,50],{},"Example components for a SaaS product:",[52,53,54,58,61,64,67,70],"ul",{},[55,56,57],"li",{},"API",[55,59,60],{},"Web application",[55,62,63],{},"Authentication",[55,65,66],{},"Payment processing",[55,68,69],{},"Webhooks and integrations",[55,71,72],{},"Email delivery",[12,74,75],{},"Each component shows one of four states:",[52,77,78,84,90,96],{},[55,79,80,83],{},[15,81,82],{},"Operational"," — working normally",[55,85,86,89],{},[15,87,88],{},"Degraded performance"," — working but slower or partially limited",[55,91,92,95],{},[15,93,94],{},"Partial outage"," — some users or regions affected",[55,97,98,101],{},[15,99,100],{},"Major outage"," — service unavailable",[12,103,104],{},"Granular components are more useful than a single \"all systems operational\" indicator. A payment processor outage affects customers differently than a documentation site going down.",[41,106,108],{"id":107},"incident-history","Incident History",[12,110,111],{},"Display at least 90 days of past incidents with:",[52,113,114,117,120,123],{},[55,115,116],{},"Start time, end time, and total duration",[55,118,119],{},"What was affected",[55,121,122],{},"A timeline of status updates during the incident",[55,124,125],{},"Root cause summary after resolution",[12,127,128],{},"Incident history is proof of your track record. Customers evaluating your service before signing a contract will check your status page. A history showing fast detection, transparent updates, and thorough postmortems builds more trust than a page with no incidents at all — because a blank history usually means no monitoring, not no problems.",[41,130,132],{"id":131},"uptime-graph","Uptime Graph",[12,134,135],{},"A rolling 90-day uptime visualization per component shows reliability at a glance. Most status page tools generate this automatically from your monitoring data.",[41,137,139],{"id":138},"subscribe-to-updates","Subscribe to Updates",[12,141,142],{},"Let customers opt into email or SMS notifications when incidents open or resolve. This removes the need for customers to refresh your status page — they get notified automatically.",[23,144,146],{"id":145},"writing-good-incident-updates","Writing Good Incident Updates",[12,148,149],{},"The most common status page failure is not the lack of a page. It's a page that exists but goes silent during an incident.",[41,151,153],{"id":152},"what-to-write-at-each-stage","What to write at each stage",[12,155,156],{},[15,157,158],{},"When the incident opens (first 5 minutes):",[160,161,166],"pre",{"className":162,"code":164,"language":165},[163],"language-text","Investigating — We are aware of issues affecting [component]. \nEngineers are investigating. Next update in 30 minutes.\n","text",[167,168,164],"code",{"__ignoreMap":169},"",[12,171,172],{},"You do not need to know the cause to post the first update. Acknowledge the issue fast. Silence for 20 minutes is worse than a one-line \"we're looking into it.\"",[12,174,175],{},[15,176,177],{},"During investigation:",[160,179,182],{"className":180,"code":181,"language":165},[163],"Identified — We have identified the cause of the [component] issue: \n[brief description, e.g., \"a database connection pool exhaustion \naffecting API response times\"]. A fix is being deployed. \nEstimated resolution: 45 minutes.\n",[167,183,181],{"__ignoreMap":169},[12,185,186],{},"Name the cause when you know it. Customers respect transparency. Vague updates (\"we're still investigating\") every 30 minutes erode trust faster than silence.",[12,188,189],{},[15,190,191],{},"On resolution:",[160,193,196],{"className":194,"code":195,"language":165},[163],"Resolved — The [component] issue has been resolved. Service is fully \noperational as of [time]. The incident affected [% of users \u002F specific \nregions]. A full postmortem will be posted within 48 hours.\n",[167,197,195],{"__ignoreMap":169},[12,199,200],{},"Promise a postmortem and follow through. A linked postmortem after a significant outage is one of the highest-trust signals you can send.",[41,202,204],{"id":203},"update-frequency","Update frequency",[12,206,207],{},"During an active incident, post updates every 15–30 minutes. If you have nothing new to report, post that:",[160,209,212],{"className":210,"code":211,"language":165},[163],"Still monitoring — The fix has been deployed and we are monitoring \nfor full recovery. Service appears to be recovering. No further impact observed.\n",[167,213,211],{"__ignoreMap":169},[12,215,216],{},"Customers are watching. Silence means you forgot about them.",[23,218,220],{"id":219},"custom-domain-and-branding","Custom Domain and Branding",[12,222,223,224,227],{},"Host your status page on a custom subdomain: ",[167,225,226],{},"status.yourdomain.com",". This serves two purposes:",[229,230,231,234],"ol",{},[55,232,233],{},"It reinforces that the status page belongs to your company (not a third-party tool)",[55,235,236,237,239],{},"When your main domain has DNS problems, ",[167,238,226],{}," may still be accessible if it's on independent infrastructure",[12,241,242],{},"Never host your status page on the same server as the service it monitors. If your server goes down, the status page goes down with it. Use a managed status page service (like Vantaj) that runs on independent infrastructure.",[23,244,246],{"id":245},"automatic-vs-manual-status-updates","Automatic vs. Manual Status Updates",[12,248,249],{},"There are two ways to update a status page during an incident:",[12,251,252,255],{},[15,253,254],{},"Automatic"," — Your monitoring tool detects an outage and updates the status page in real time, without human intervention. Components flip from \"Operational\" to \"Degraded\" or \"Outage\" the moment the monitoring detects failure.",[12,257,258,261],{},[15,259,260],{},"Manual"," — An engineer types the incident updates during the outage.",[12,263,264],{},"Both are necessary. Automatic updates catch outages immediately, even at 3 AM with nobody watching. Manual updates provide context, root cause analysis, and estimated resolution times that no automation can supply.",[12,266,267],{},"Vantaj connects your monitors directly to your status page. When a monitor enters a DOWN state, the affected component updates automatically. Engineers add the narrative context through manual update posts.",[23,269,271],{"id":270},"what-not-to-do","What Not to Do",[12,273,274,277],{},[15,275,276],{},"Never mark everything \"Operational\" during a known outage."," Customers are experiencing the problem. A status page claiming everything is fine while users can't log in destroys trust permanently. One of the most damaging things a company can do during an outage is maintain a green status page.",[12,279,280,283],{},[15,281,282],{},"Do not over-aggregate components."," A single \"Platform\" component that covers your API, authentication, database, and payments tells customers nothing useful when half of those services are affected.",[12,285,286,289],{},[15,287,288],{},"Do not post vague updates."," \"We're experiencing issues with some services\" helps no one. Name the component, describe the symptom, and give a timeline estimate.",[12,291,292,295],{},[15,293,294],{},"Do not let the history go blank."," A status page with no incidents in 12 months is not impressive — it signals that either the service never has issues (unlikely) or that incidents are not being reported (more likely). Transparent incident history builds more credibility than a spotless record.",[23,297,299],{"id":298},"setting-up-a-status-page-with-vantaj","Setting Up a Status Page with Vantaj",[229,301,302,305,308,311,317,320],{},[55,303,304],{},"Navigate to Status Pages in your Vantaj dashboard",[55,306,307],{},"Create a new status page and add your components",[55,309,310],{},"Connect each component to the relevant monitors — status updates automatically when monitors change state",[55,312,313,314,316],{},"Add your custom domain (",[167,315,226],{},") under domain settings",[55,318,319],{},"Configure subscriber notifications (email and SMS)",[55,321,322],{},"Add your branding: logo, colors, support link",[12,324,325],{},"The page goes live immediately. No code, no hosting configuration, no maintenance.",[12,327,328],{},"Components inherit their status from your monitors: if your API monitor enters a DOWN state, the API component on your status page flips to \"Major Outage\" within seconds. When the monitor recovers, the component restores automatically.",[23,330,332],{"id":331},"frequently-asked-questions","Frequently Asked Questions",[41,334,336],{"id":335},"do-i-need-a-status-page-if-i-have-monitoring-alerts","Do I need a status page if I have monitoring alerts?",[12,338,339],{},"Monitoring alerts tell your team about problems. A status page tells your customers. They serve different audiences. Your on-call engineer gets paged; your customer visits a URL to check if the problem is known. Both are necessary.",[41,341,343],{"id":342},"should-my-status-page-be-public-or-private","Should my status page be public or private?",[12,345,346],{},"Public by default. If your customers are external (B2C or B2B), your status page should be publicly accessible without login. Internal tools for a small team can use a private page, but external-facing products benefit from transparency.",[41,348,350],{"id":349},"how-much-detail-should-i-include-in-incident-updates","How much detail should I include in incident updates?",[12,352,353],{},"Enough to be useful without creating liability. Name the affected component, describe the user impact (\"users may experience login failures\"), provide a timeline estimate, and acknowledge the root cause when known. Avoid committing to specific cause-and-effect chains until you're certain (\"a misconfigured deployment\" is fine; \"a bug in our database query optimizer\" before you've confirmed it is not).",[41,355,357],{"id":356},"what-is-a-good-response-time-for-posting-the-first-update","What is a good response time for posting the first update?",[12,359,360],{},"Under 10 minutes from when the incident is detected. If your monitoring detects the incident automatically and triggers an alert, your first update should go up before the on-call engineer has finished their initial investigation. The first update does not need to contain the cause — it just needs to acknowledge that you know.",[41,362,364],{"id":363},"does-a-status-page-hurt-my-reputation-when-i-have-outages","Does a status page hurt my reputation when I have outages?",[12,366,367],{},"A visible status page during an outage improves customer perception compared to silence. A 2023 Statuspage survey found that 76% of enterprise buyers consider vendor status pages when evaluating reliability, and the majority prefer transparent incident reporting over a vendor claiming near-perfect uptime with no history.",{"title":169,"searchDepth":369,"depth":369,"links":370},2,[371,372,379,383,384,385,386,387],{"id":25,"depth":369,"text":26},{"id":38,"depth":369,"text":39,"children":373},[374,376,377,378],{"id":43,"depth":375,"text":44},3,{"id":107,"depth":375,"text":108},{"id":131,"depth":375,"text":132},{"id":138,"depth":375,"text":139},{"id":145,"depth":369,"text":146,"children":380},[381,382],{"id":152,"depth":375,"text":153},{"id":203,"depth":375,"text":204},{"id":219,"depth":369,"text":220},{"id":245,"depth":369,"text":246},{"id":270,"depth":369,"text":271},{"id":298,"depth":369,"text":299},{"id":331,"depth":369,"text":332,"children":388},[389,390,391,392,393],{"id":335,"depth":375,"text":336},{"id":342,"depth":375,"text":343},{"id":349,"depth":375,"text":350},{"id":356,"depth":375,"text":357},{"id":363,"depth":375,"text":364},"tutorials","2026-06-25","A status page tells your customers what's working and what isn't. Here's how to set one up, what information to include during an incident, and the mistakes that make status pages worse than useless.","md",null,{},true,"\u002Fblog\u002Fhow-to-set-up-a-status-page",7,{"title":5,"description":396},"blog\u002Fhow-to-set-up-a-status-page","Gu932YANMePbN_Z3k_rDVaLFq8iO-t_7DjVowEvspkc",1782428926831]