English and Russian status pages for one SaaS product
You sell to English-first buyers, Russian-speaking teams, or both. During an outage they open whatever link is in the contract — and the page should read naturally in that language, not feel like a machine translation of your marketing site.
StillOnline hosts one status page per project with localized UI at stillonline.tech/s/... and stillonline.tech/ru/s/.... The same checks and incident history power both URLs. You write incident updates in your own words; the shell (labels, timestamps, subscribe flow) follows the locale prefix. Free covers one project; Pro scales when you split products or regions.
Quick answer
StillOnline serves each project’s public status page at https://stillonline.tech/s/{project-id} (English UI) and https://stillonline.tech/ru/s/{project-id} (Russian UI). Both URLs show the same checks and incidents; only interface copy and date formatting differ. Put the link that matches your buyer’s docs language in contracts and onboarding. Owner alerts use one account-wide StillOnline Telegram bot link (Telegram guide). Custom domains for the status hostname are not offered.
How locale URLs map to one project
StillOnline’s marketing site and status pages share the same locale model: English without a prefix, Russian under /ru.
| Surface | English | Russian |
|---|---|---|
| Status page (visitors) | /s/{project-id} | /ru/s/{project-id} |
| Public JSON | api.stillonline.tech/v1/public/status/{id} | same payload |
| Your dashboard | /app | /ru/app |
| This blog | /blog/... | /ru/blog/... |
You do not create two projects just for language. One project, one health URL, two shareable links for humans who prefer EN or RU chrome.
Which link to give which customer
Match the status URL to the language of the document where the link lives, not to where your servers run.
| Buyer context | Share |
|---|---|
| EN security pack, US/EU contract | https://stillonline.tech/s/{id} |
| RU договор, российский B2B, СНГ support | https://stillonline.tech/ru/s/{id} |
| Mixed team (EN eng + RU support) | Pick one primary in the contract; mention the other locale in parentheses |
| Public README (open source) | Default EN link; one line “Русский: /ru/s/…” |
If both links appear in the same email, label them (“Status (EN)” / “Статус (RU)”) so mobile clients do not look like duplicate spam.
What StillOnline translates vs what you write
The page chrome — status labels, “Subscribe with Google”, check rows, maintenance banners — comes from StillOnline’s en / ru dictionaries. Incident titles and bodies are what you type in the dashboard; they are not auto-translated. For bilingual buyers you can:
- Write incidents in the language your on-call uses, and add a short second paragraph in the other language when it matters, or
- Post in one language and link to a Notion/runbook translation for legal-heavy outages.
Operational checks and uptime math are identical on both URLs; only presentation locale changes.
Where to standardize links internally
Use one canonical locale in your runbook, then mirror the other where sales already localized assets.
- Health URL — one production
GET /health(quickstart). - StillOnline project — name matches the product customers recognize.
- EN pack — status URL in EN onboarding + questionnaire.
- RU pack —
/ru/s/...in RU onboarding and support macros (B2B trust). - Owner alerts — connect Telegram, Slack, or email once in settings; messages include the project name (Telegram).
Wait 2–3 probe cycles after creating the check before you send either locale link to enterprise buyers.
Limits that matter for two-language GTM
| Plan | EN + RU links |
|---|---|
| Free | 1 project → one pair of locale URLs |
| Pro | Up to 10 projects — separate products or separate client sites, each with /s + /ru/s |
| Ultimate | Same URL model; shorter check intervals |
StillOnline does not host your status page on status.yourbrand.com. You sell transparency on stillonline.tech, not white-label hostname — same as public status guide.
Related guides
- B2B status page trust
- Public status page for SaaS
- Agency: multiple client status pages
- Telegram owner alerts
FAQ
Does StillOnline require two projects for English and Russian status pages?
No. One project exposes both /s/{id} and /ru/s/{id} with the same checks. Use multiple projects only when you monitor different products or clients (agency guide).
Will incidents auto-translate between EN and RU on StillOnline?
No. You control incident text in the dashboard. UI strings (operational / degraded / down) follow the URL locale. For bilingual outages, write both languages in one incident or link to an external post (incident template).
Which StillOnline status URL should we put in a Russian B2B contract?
Use https://stillonline.tech/ru/s/{project-id} when the contract and support runbooks are in Russian. Use the non-/ru URL for English-primary security reviews. Both stay valid for the life of the project.
Do StillOnline owner alerts respect locale?
Alerts go to email, Telegram (StillOnline bot), or Slack in the language you configure in those channels; the message includes project name and check state. Setup: Telegram guide · Pricing (Free = one owner channel).
Can we embed StillOnline status in our own EN/RU marketing site?
Use the public JSON API for widgets (REST guide) or link out to the hosted page. Do not hide the StillOnline URL in a footer only — put it in docs and onboarding (launch checklist).
Does StillOnline support more than EN and RU locales on the status page?
Today the product ships en and ru for the marketing site and status UI. Additional locales are not offered; pick the closest match for your buyers and write incidents in their language.