Status pages

Per status page a single CNAME (status.example.com → status.xictraq.com); where your provider does not allow a CNAME at that name, A and AAAA records pointing at our edge addresses do the job. Both options are shown in the editor with a copy button. After saving we check the record on demand, and the Let's Encrypt certificate is issued automatically on the first request. The custom domain is an add-on at EUR 5 per domain and month, bookable on every plan. Without a custom domain the status page keeps running on www.xictraq.com/en/status?token=… (fully working and shareable).

Logo, primary colour and company name are automatically pulled from your white-label config (alert_configs.whitelabel). Once a company name is set, the Powered-by-XICTRAQ footer is dropped automatically — no extra toggle needed.

Visitors click “+ Subscribe to updates”, enter email, confirm via mail link. When a website's status changes they automatically receive an update; the comparison runs every 5 minutes, so an outage that starts and ends between two comparisons triggers no email. Unsubscribe link in every mail. GDPR-compliant.

At api.xictraq.com/api/public/status.rss?token=... you get the history of your status page as an Atom feed (last 60 days): per website one entry for every day with failed checks on which it was not at least 99.9% available (site name, date, number of failed checks and the daily ratio; up to 200), plus one entry per update of a reported incident with title, stage and text, and one per scheduled maintenance slot with its time window. Useful for Slack/Teams RSS bots or your own status aggregators. A private or non-public status page returns no feed.

One script tag, three styles: badge (compact pill with status dot), banner (full-width status strip with the overall status on the left and the number of monitored websites on the right), card (block with one row per website including 30-day uptime). Themes light / dark / auto via the data-theme attribute; on the Agency plan the widget automatically picks up your white-label colours and logo. The widget loads the status over the token URL and refreshes itself every 5 minutes. Optional: data-lang="de|en" forces the language (without it the widget follows the browser language), data-link sets the target host of the link in case you later serve the status page on your own domain.

For READMEs, Markdown docs or an email signature XICTRAQ serves a static SVG image — no JavaScript and no CSP change required. At api.xictraq.com/api/public/status/badge?token=...&metric=status it shows "operational", "maintenance", "degraded" or "down" ("n/a" without a measurement); websites and API endpoints of the page count as on the page itself, and so do open reported incidents: impact “Critical” or “Major” yields "down", “Minor” yields "degraded", “None” changes nothing. With metric=uptime it shows the 30-day uptime ratio instead (e.g. 99.91%). The colour reflects the value and the image is cacheable for 5 minutes. For a private (password-protected) status page the badge deliberately returns "private" instead of a live status.

Not every incident is auto-detectable (e.g. “SEPA debits delayed” — no technical check sees this). For these, go to /app/status-pages → edit status page → “Incidents” and create one manually (title + impact), post updates along the lifecycle “Investigating” → “Identified” → “Monitoring” → “Resolved”, and get a chronological timeline per incident. Active incidents appear prominently at the top of the status page and also determine the overall status (in the widget and SVG badge too): impact “Critical” or “Major” shows “Incident detected”, “Minor” shows “Partially degraded”, “None” leaves it unchanged. Resolved ones move automatically into the “Past incidents” section (last 10). Confirmed subscribers receive an email on every update.

In addition to websites, individual API-Monitoring endpoints can be lifted into their own components on the status page — analogous to the “API Server” row on xictraq.com/de/status. Per endpoint: method badge (GET/POST/…), last response time, 30-day uptime and 90-day bars from api_endpoint_checks. Configure at /app/status-pages → edit status page → "API endpoints (optional)".

Sort monitored websites into named groups (e.g. “Frontend”, “Payments”, “Infrastructure”). On the public page components appear per group with a roll-up status. Up to 20 groups per status page, each with a name (max 80 characters).

Set an optional SLA target in percent (e.g. 99.90). The public page compares it against the actual 30-day uptime and shows “target met” or “target missed”. Leave the field empty to hide the target.

Each status page can be switched to “private”: visitors then have to enter a password you set before they can see the status. The password is stored hashed and never sent to clients; without the correct password the public response only returns the title and the information that a password is required. The status badge also reveals no live status for a private page.

Per status page you announce maintenance windows with title, description, start and end time. Active and upcoming windows (up to 14 days ahead) appear on the public page. Optionally recurring (weekly or monthly) — expired windows automatically roll over to the next occurrence. Around 60 minutes before the start, confirmed subscribers receive a reminder.

Per stage “Investigating” → “Identified” → “Monitoring” → “Resolved” the assistant generates two building blocks: an internal first assessment (technical triage, for your team only) and a customer-ready status page update draft in German and English. It also suggests a fitting impact (none/minor/major/critical) and a status — which you can apply, change or discard freely.

The draft is based on the incident XICTRAQ has detected anyway, together with automatically captured diagnostics: DNS resolution, HTTP response/status code and the ASN/network operator of the affected host. From this the assistant formulates a plausible, customer-friendly description — without you having to prepare the raw technical data yourself. Optionally you link an already open internal incident so the draft ties into its history.

The assistant lists currently conspicuous hosts as suggestions: title, severity, affected host, start time and last HTTP status — and flags whether an open public incident already exists on the status page. This lets you draft an update for exactly the outage in progress with one click, instead of searching manually.

If the AI is temporarily unreachable or the daily quota (20 drafts per account per day) is used up, the assistant returns vetted standard texts per lifecycle stage (DE/EN) instead of nothing. You can see the source of the draft (AI or standard text) and trigger a fresh generation at any time — the publishing path stays identical and manual in both cases.