Where to link your StillOnline status page (without footer spam)
A status page nobody can find fails during the first real outage. Stuffing the link in every footer trains users to ignore it and looks like SEO clutter — StillOnline editorial policy matches that: no permanent footer link.
Put stillonline.tech/{locale}/s/{id} where technical buyers and support already look.
Security frameworks expect a single communication channel during incidents — same idea as NIST incident handling: document where stakeholders read live status before the outage happens.
Quick answer
Link your StillOnline status page in developer docs, API README, B2B onboarding, security/vendor questionnaires, and support macros — not the marketing site footer. Send the URL during an active incident or when a customer asks. Free includes one public page; Pro adds a private page for internal teams — public vs private. Subscribers use Google email on the public page; that is separate from owner Telegram/Slack alerts.
Recommended placements
| Location | Why it works |
|---|---|
| Docs → “System status” | Integrators bookmark before incidents |
| API reference intro | “Uptime and incidents” paragraph |
| Onboarding email (B2B) | Sets expectation before first outage |
| Security / vendor form | “Public availability page” field — questionnaire guide |
| Help center article | “How to check if we’re down” |
| Sales security pack PDF | One line + screenshot |
| Incident reply macro | Paste live URL |
Avoid: global footer, login screen fine print, every blog post signature. Security reviewers often ask for a “public status URL” field — NIST SP 800-61 treats consistent incident communication as part of response planning, not marketing.
What not to do
| Anti-pattern | Better |
|---|---|
| Footer on every page | Docs + on-demand during incidents |
| Hiding URL until outage | Proactive link in onboarding |
| Different URLs per locale | One canonical /s/{id}; StillOnline serves en and ru UI |
| Replacing status page with Twitter | Social vs status page |
Copy snippets
Docs one-liner:
Live service status and incident history: status page.
Support macro:
Check our status page for current impact and updates: https://stillonline.tech/s/your-id
StillOnline setup
- Create project → public page — quickstart.
- Copy
/s/{id}from dashboard. - Add to docs repo (not footer component).
- Pro: optional private link for staff only — same checks, different visibility.
Related guides
- Public status page guide
- B2B status page trust
- Security questionnaire answers
- Public vs private status page
FAQ
Does StillOnline require a footer link?
No. Editorial style explicitly discourages footer placement.
Should the status link be in the app UI?
Optional “System status” in settings or help — not required on every screen.
Can I use different StillOnline pages for docs vs customers?
One public page per project is typical; Pro supports private pages for internal viewers.
RU customers — same URL?
Yes. Page UI follows locale; URL pattern is the same hosted link.