[{"data":1,"prerenderedAt":647},["ShallowReactive",2],{"\u002Fblog\u002Fhow-to-set-up-status-page":3},{"id":4,"title":5,"author":6,"body":8,"category":635,"date":636,"description":637,"extension":638,"image":639,"lastUpdated":639,"meta":640,"navigation":641,"path":642,"readingTime":643,"seo":644,"stem":645,"__hash__":646},"blog\u002Fblog\u002Fhow-to-set-up-status-page.md","How to Set Up a Public Status Page in 5 Minutes",{"name":7},"Vantaj Team",{"type":9,"value":10,"toc":611},"minimark",[11,16,20,23,26,30,33,46,49,53,65,68,71,75,78,83,101,106,120,123,128,140,143,212,215,219,226,229,250,263,267,270,273,284,287,291,294,369,372,376,379,411,414,418,421,424,470,473,477,480,494,497,501,505,508,512,515,519,522,526,529,533,608],[12,13,15],"h2",{"id":14},"your-customers-shouldnt-have-to-guess","Your Customers Shouldn't Have to Guess",[17,18,19],"p",{},"When your service goes down, your customers do one of three things: check Twitter, email support, or assume you don't know. All three are bad for you. The first spreads negative sentiment. The second floods your inbox. The third erodes trust.",[17,21,22],{},"A public status page gives them a fourth option - a single URL where they can see exactly what's happening, what's affected, and whether you're working on it. No guesswork, no support tickets, no speculation.",[17,24,25],{},"If you've been putting off setting one up because it seemed like a project, it isn't. Here's how to go from nothing to a live, public status page in about 5 minutes.",[12,27,29],{"id":28},"what-you-need-before-you-start","What You Need Before You Start",[17,31,32],{},"Before creating a status page, you need monitors running on the services you want to display. If you haven't set those up yet, it takes about 60 seconds per monitor:",[34,35,36,40,43],"ol",{},[37,38,39],"li",{},"Add the URL of each service you want to track (your app, API, marketing site, etc.)",[37,41,42],{},"Set the check interval and alert preferences",[37,44,45],{},"Let the monitors collect a few minutes of data",[17,47,48],{},"Once your monitors are running, the status page simply reflects their state. There's nothing extra to configure - no separate infrastructure, no webhooks to wire up, no manual updating during incidents.",[12,50,52],{"id":51},"step-1-create-the-status-page","Step 1: Create the Status Page",[17,54,55,56,60,61,64],{},"In your Vantaj dashboard, navigate to ",[57,58,59],"strong",{},"Status Pages"," and click ",[57,62,63],{},"Create status page",".",[17,66,67],{},"Give it a name that your customers will recognize. This appears as the page title, so use your product name - not an internal codename. Something like \"Acme Status\" or \"YourApp Status.\"",[17,69,70],{},"That's it for the basic setup. Your status page is now live at a Vantaj-hosted URL. But you'll want to configure it further before sharing it.",[12,72,74],{"id":73},"step-2-choose-which-monitors-to-display","Step 2: Choose Which Monitors to Display",[17,76,77],{},"Not every monitor belongs on your public status page. Internal health checks, staging environments, and third-party vendor monitors are useful for your team but confusing for customers.",[17,79,80],{},[57,81,82],{},"Show these:",[84,85,86,89,92,95,98],"ul",{},[37,87,88],{},"Your primary web application",[37,90,91],{},"Your API (if customers interact with it directly)",[37,93,94],{},"Authentication \u002F login",[37,96,97],{},"Payment processing or checkout",[37,99,100],{},"Email delivery (if customers depend on transactional emails)",[17,102,103],{},[57,104,105],{},"Don't show these:",[84,107,108,111,114,117],{},[37,109,110],{},"Internal admin panels",[37,112,113],{},"Staging or development environments",[37,115,116],{},"Infrastructure-level checks (database, Redis, etc.)",[37,118,119],{},"Third-party vendor status (Stripe, AWS, etc.)",[17,121,122],{},"The rule: if a customer would recognize the service name and care about its status, include it. If it's an internal implementation detail, leave it off.",[124,125,127],"h3",{"id":126},"naming-your-monitors-for-public-display","Naming Your Monitors for Public Display",[17,129,130,131,135,136,139],{},"Your internal monitor might be called ",[132,133,134],"code",{},"prod-api-us-east-health"," or ",[132,137,138],{},"https:\u002F\u002Fapi.example.com\u002Fv2\u002Fhealth",". Your customers don't need to see that.",[17,141,142],{},"Rename the monitors on your status page to use customer-friendly labels:",[144,145,146,159],"table",{},[147,148,149],"thead",{},[150,151,152,156],"tr",{},[153,154,155],"th",{},"Internal Name",[153,157,158],{},"Public Display Name",[160,161,162,172,182,192,202],"tbody",{},[150,163,164,169],{},[165,166,167],"td",{},[132,168,134],{},[165,170,171],{},"API",[150,173,174,179],{},[165,175,176],{},[132,177,178],{},"https:\u002F\u002Fapp.example.com",[165,180,181],{},"Web Application",[150,183,184,189],{},[165,185,186],{},[132,187,188],{},"https:\u002F\u002Fapp.example.com\u002Flogin",[165,190,191],{},"Authentication",[150,193,194,199],{},[165,195,196],{},[132,197,198],{},"stripe-checkout-flow",[165,200,201],{},"Payments",[150,203,204,209],{},[165,205,206],{},[132,207,208],{},"postmark-delivery-check",[165,210,211],{},"Email Delivery",[17,213,214],{},"Clear, simple names reduce confusion during incidents and make the page useful for non-technical customers.",[12,216,218],{"id":217},"step-3-connect-a-custom-domain-optional-but-recommended","Step 3: Connect a Custom Domain (Optional but Recommended)",[17,220,221,222,225],{},"By default, your status page is hosted on a Vantaj subdomain. It works, but a custom domain like ",[132,223,224],{},"status.yourcompany.com"," looks more professional and reinforces that the page is officially yours.",[17,227,228],{},"To set it up:",[34,230,231,237,244,247],{},[37,232,233,234,236],{},"In your status page settings, enter your custom domain (e.g., ",[132,235,224],{},")",[37,238,239,240,243],{},"Add a ",[57,241,242],{},"CNAME record"," in your DNS provider pointing to the value Vantaj provides",[37,245,246],{},"Wait for DNS propagation (usually a few minutes, occasionally up to an hour)",[37,248,249],{},"Vantaj automatically provisions an SSL certificate for the custom domain",[17,251,252,253,256,257,259,260,64],{},"One important detail: ",[57,254,255],{},"host your status page on a different domain or subdomain than your main application",". If your primary domain's DNS goes down, your status page should still be reachable. A subdomain like ",[132,258,224],{}," works because it can resolve independently - but if you want maximum independence, consider a completely separate domain like ",[132,261,262],{},"yourcompanystatus.com",[12,264,266],{"id":265},"step-4-enable-subscriber-notifications","Step 4: Enable Subscriber Notifications",[17,268,269],{},"A status page that customers have to manually check during an outage only helps the customers who remember to check. Subscriber notifications close the gap - customers opt in, and they receive email updates whenever an incident opens, updates are posted, or services recover.",[17,271,272],{},"Enable email subscriptions in your status page settings. Then encourage your customers to subscribe:",[84,274,275,278,281],{},[37,276,277],{},"Add a \"Subscribe to updates\" callout on the status page itself",[37,279,280],{},"Mention it in your onboarding emails",[37,282,283],{},"Link to it from your support documentation",[17,285,286],{},"Subscribers get notified proactively, which means fewer support tickets, fewer \"is it down?\" messages, and more trust during incidents.",[12,288,290],{"id":289},"step-5-share-the-url","Step 5: Share the URL",[17,292,293],{},"A status page nobody can find is a status page that doesn't work. Make it discoverable:",[144,295,296,306],{},[147,297,298],{},[150,299,300,303],{},[153,301,302],{},"Location",[153,304,305],{},"Why",[160,307,308,318,328,338,348,359],{},[150,309,310,315],{},[165,311,312],{},[57,313,314],{},"App footer",[165,316,317],{},"Customers see it on every page",[150,319,320,325],{},[165,321,322],{},[57,323,324],{},"Login page",[165,326,327],{},"First place users check when they can't sign in",[150,329,330,335],{},[165,331,332],{},[57,333,334],{},"Documentation \u002F help center",[165,336,337],{},"Where users go to troubleshoot",[150,339,340,345],{},[165,341,342],{},[57,343,344],{},"Support auto-replies",[165,346,347],{},"Deflects tickets during incidents",[150,349,350,356],{},[165,351,352,355],{},[57,353,354],{},"Email signatures"," (support team)",[165,357,358],{},"Passive awareness in every interaction",[150,360,361,366],{},[165,362,363],{},[57,364,365],{},"Error pages (5xx)",[165,367,368],{},"Catches users at the exact moment they need it",[17,370,371],{},"The more visible your status page is, the more support tickets it absorbs. Teams with well-linked status pages consistently report 40–60% fewer \"is it down?\" tickets during incidents.",[12,373,375],{"id":374},"what-happens-during-an-incident","What Happens During an Incident",[17,377,378],{},"Once your status page is live, here's what happens when a monitor fails:",[34,380,381,387,393,399,405],{},[37,382,383,386],{},[57,384,385],{},"Vantaj detects the failure"," - Multi-region consensus verification confirms it's a real outage, not a network blip.",[37,388,389,392],{},[57,390,391],{},"The status page updates automatically"," - The affected service changes from \"Operational\" to \"Down\" in real time. No manual action needed.",[37,394,395,398],{},[57,396,397],{},"Subscribers are notified"," - Anyone subscribed to email updates receives an incident notification.",[37,400,401,404],{},[57,402,403],{},"Your team posts updates"," (optional) - You can add manual timeline updates from the Vantaj dashboard: \"Investigating,\" \"Identified,\" \"Fix deployed,\" \"Resolved.\"",[37,406,407,410],{},[57,408,409],{},"The monitor recovers"," - When the service comes back, the status page updates to \"Operational\" and a recovery notification is sent to subscribers.",[17,412,413],{},"The entire cycle - from detection to communication to recovery - happens without requiring someone on your team to manually update the status page. During an incident, your engineers can focus on fixing the problem instead of communicating about it.",[12,415,417],{"id":416},"posting-manual-updates-during-incidents","Posting Manual Updates During Incidents",[17,419,420],{},"Automatic status changes handle the basics, but customers want more than just \"down\" and \"up.\" They want to know what's happening.",[17,422,423],{},"Write status updates for your customers, not your engineering team:",[144,425,426,436],{},[147,427,428],{},[150,429,430,433],{},[153,431,432],{},"What to write",[153,434,435],{},"What NOT to write",[160,437,438,446,454,462],{},[150,439,440,443],{},[165,441,442],{},"\"We're investigating increased error rates on the API\"",[165,444,445],{},"\"pg_stat_activity shows 847 idle-in-transaction connections on the primary replica\"",[150,447,448,451],{},[165,449,450],{},"\"We've identified the cause and are deploying a fix\"",[165,452,453],{},"\"The connection pool exhaustion was caused by a missing statement_timeout in the pgbouncer config\"",[150,455,456,459],{},[165,457,458],{},"\"Fix deployed - monitoring recovery\"",[165,460,461],{},"\"Rolled back commit abc123 and applied hotfix to prod-us-east-1\"",[150,463,464,467],{},[165,465,466],{},"\"All services operational\"",[165,468,469],{},"\"All pods healthy, p99 latency back to baseline\"",[17,471,472],{},"Keep it simple, honest, and focused on impact and progress. Your customers care about \"is it fixed?\" - not the technical details of how.",[12,474,476],{"id":475},"scheduled-maintenance-announcements","Scheduled Maintenance Announcements",[17,478,479],{},"Status pages aren't just for incidents. Use them to communicate planned maintenance:",[34,481,482,485,488,491],{},[37,483,484],{},"Create a maintenance window in your Vantaj dashboard",[37,486,487],{},"Set the start time, expected duration, and affected services",[37,489,490],{},"Add a description: \"Scheduled database maintenance - brief API interruption expected\"",[37,492,493],{},"The status page displays the upcoming maintenance, and subscribers are notified in advance",[17,495,496],{},"Pre-announced maintenance is the difference between \"our provider had an outage\" and \"they told us about it in advance.\" Customers plan around it instead of panicking.",[12,498,500],{"id":499},"status-page-best-practices","Status Page Best Practices",[124,502,504],{"id":503},"keep-the-component-list-short","Keep the Component List Short",[17,506,507],{},"Five to eight services is ideal. More than that and the page becomes a wall of status indicators that's hard to scan. If you have 20+ microservices, group them into customer-facing categories (Web App, API, Payments, Email) rather than listing each one individually.",[124,509,511],{"id":510},"dont-hide-incidents","Don't Hide Incidents",[17,513,514],{},"A status page that always shows green loses credibility. Customers know you've had issues - if the page never reflects them, they'll stop trusting it. Post real incidents, show real uptime data, and let the history speak for itself. Transparency builds more trust than a perfect record.",[124,516,518],{"id":517},"update-during-incidents-even-if-theres-no-news","Update During Incidents, Even If There's No News",[17,520,521],{},"During a prolonged incident, silence is worse than \"still investigating.\" Post an update every 15–30 minutes, even if it's just \"We're continuing to investigate and will update when we have more information.\" It confirms you're aware and actively working on it.",[124,523,525],{"id":524},"use-it-for-positive-communication-too","Use It for Positive Communication Too",[17,527,528],{},"Status pages don't have to be only for bad news. Post when you complete infrastructure upgrades, expand to new regions, or improve redundancy. It shows customers you're actively investing in reliability.",[12,530,532],{"id":531},"the-5-minute-setup-checklist","The 5-Minute Setup Checklist",[144,534,535,548],{},[147,536,537],{},[150,538,539,542,545],{},[153,540,541],{},"Step",[153,543,544],{},"Time",[153,546,547],{},"Done?",[160,549,550,561,571,580,590,599],{},[150,551,552,555,558],{},[165,553,554],{},"Create status page and name it",[165,556,557],{},"30 sec",[165,559,560],{},"☐",[150,562,563,566,569],{},[165,564,565],{},"Select monitors to display",[165,567,568],{},"1 min",[165,570,560],{},[150,572,573,576,578],{},[165,574,575],{},"Rename monitors for public display",[165,577,568],{},[165,579,560],{},[150,581,582,585,588],{},[165,583,584],{},"Set up custom domain (CNAME)",[165,586,587],{},"2 min",[165,589,560],{},[150,591,592,595,597],{},[165,593,594],{},"Enable subscriber notifications",[165,596,557],{},[165,598,560],{},[150,600,601,604,606],{},[165,602,603],{},"Add status page link to app footer and login page",[165,605,568],{},[165,607,560],{},[17,609,610],{},"Your status page is now live, automatically updated, and accessible to every customer. The next time something goes down, your users will have a place to check - and your support team will have a fraction of the tickets they'd normally get.",{"title":612,"searchDepth":613,"depth":613,"links":614},"",2,[615,616,617,618,622,623,624,625,626,627,628,634],{"id":14,"depth":613,"text":15},{"id":28,"depth":613,"text":29},{"id":51,"depth":613,"text":52},{"id":73,"depth":613,"text":74,"children":619},[620],{"id":126,"depth":621,"text":127},3,{"id":217,"depth":613,"text":218},{"id":265,"depth":613,"text":266},{"id":289,"depth":613,"text":290},{"id":374,"depth":613,"text":375},{"id":416,"depth":613,"text":417},{"id":475,"depth":613,"text":476},{"id":499,"depth":613,"text":500,"children":629},[630,631,632,633],{"id":503,"depth":621,"text":504},{"id":510,"depth":621,"text":511},{"id":517,"depth":621,"text":518},{"id":524,"depth":621,"text":525},{"id":531,"depth":613,"text":532},"tutorials","2026-06-18","A step-by-step guide to creating a public status page for your product. Connect your monitors, customize the layout, add a custom domain, and give your customers a single place to check during incidents.","md",null,{},true,"\u002Fblog\u002Fhow-to-set-up-status-page",7,{"title":5,"description":637},"blog\u002Fhow-to-set-up-status-page","x-k-cLn076enh5w9ZmfNT3sN_14tBAbrmKZjTiv0F54",1782222711179]