12 requests per minute
cap per visitor on the public widget interface
applies per visitor and assistant; that allows one question every 5 seconds, and the series waits 5.5 seconds to keep clear of our own brake
Monitored around the clock
Status and incident reports
This page describes what is monitored, how quickly an incident becomes visible and how you get told about it. It deliberately does not show the current state, because a static page could only assert it. The state of your assistant is shown in the overview of your account.
View the state in your account Report an incident
- Every answer cites its source
- Loads only after your consent
- No minimum term, cancellable monthly
- 8 of 8
- questions without a basis declined instead of guessed
- XICBOT, own measurement series of 11 September 2026
-
Visitor:Our assistant is not answering right now. Does this page say whether there is an outage?
-
Assistant:This page deliberately does not show the current state — a static page could only assert it. The state of your assistant is shown in the overview of your account.
-
Visitor:Where do I see that?
-
Assistant:The overview in your account shows the key figures for the last seven days, conversations per day and what is set up; whether a source is indexed is shown under Knowledge. Announced work goes to the address stored in the account.
- Reference · Overview in the account · key figures for the last seven days
Ask it yourself, Assistant of this website
Automated assistantWhat is monitored
An assistant on a website is part of that website: if it does not answer, your visitors see it before you do. That is why the monitoring does not only check whether servers are running, but whether the chain that produces an answer works — from delivering the widget through the interface to the answer itself. What is measured and what happens during an incident is described here.
This page shows no live valueThe state of your assistant is shown in the overview of your account, computed from live operation. A static page would have to assert a state it does not measure — and during an incident an assertion is exactly what helps nobody.
What is monitored is the chain, not the individual server. Every point is checked from outside, the way a visitor to your website reaches it, and every measurement carries a timestamp. If a measurement fails, it counts as not measured, not as fine.
Widget delivery
Is the widget file delivered and valid? This point decides whether the assistant appears on your page at all — regardless of whether it could answer.
- If the assistant's configuration cannot be loaded, the frame locks the input and writes the reason into its status line — instead of showing an empty bubble.
- If the assistant is not ready, the frame also locks, but with its own sentence. The two cases stay distinguishable.
- Locked means: input field and send button are switched off. The rest of your page is unaffected, because the widget runs in its own frame.
- Without JavaScript the widget does not appear at all. There is no fallback path for that, and it is a property of the embed, not an incident.
Interface
Does the interface accept requests and answer them within the expected time? Measured with a real request, not with a ping to the machine.
- The public status endpoint is reachable without a login and cached for a short span, so that a wave of queries does not load it further.
- Anything other than "operational" answers with error code 503. Third-party monitoring that only reads the code sees the incident without having to parse the text.
- "Not measured" and "measured and degraded" are two different states and are delivered as such. A failed measurement is not booked as green.
- When sending, the widget translates error codes 409, 429 and 403 into their own sentences. Every other error gets a collective sentence, so that no internal text reaches your page.
Answer path
Does a test question come back with an answer that references a source? This point also triggers when all machines are running but the answer fails to appear.
- Access to the language model is checked via key and port reachability, not via a real model call. A call on every measurement would consume quota that belongs to conversations.
- If the language model fails mid-stream, the half-written text is discarded and the stored fallback answer is sent instead.
- That fallback answer is a mandatory field on the assistant and must not be empty. It appears in the flow of the conversation, not as an error box.
- If a human has taken over the conversation, the stream ends without text and without a fallback answer — otherwise the assistant would write across a colleague.
Reading sources
Are sources read and indexed within the intended time? A backlog here does not cause an outage but leads to outdated answers — which is why it is tracked separately.
- Knowledge refresh and the knowledge probes that follow run on a fixed schedule, each entry with its own heartbeat.
- A failure does not overwrite the timestamp of the last success. You therefore see when something last actually worked, not when it was last attempted.
- An overdue heartbeat is recorded as a critical alert, exactly once per name — not again on every pass.
- An index run writes into a new version and only switches over at the end. A backlog delays the new state; it does not destroy the old one.
Queues
A queue growing beyond its usual length is an early sign of trouble, before it reaches the visitor.
- The queue counts as healthy as long as the oldest open job is young enough and fewer than twenty jobs failed in the last hour.
- A lane counts as stalled when no worker serves it and its oldest job is past the limit. Stalled is not the same as slow and is reported separately.
- The daemon runs as a single instance behind a file lock. A second start aborts instead of working the same jobs twice.
- On start the daemon reclaims orphaned jobs. A job that was in progress during an abort does not stay behind.
Certificates and access
Certificate validity and reachability of the login. An expired certificate silences the widget without any machine failing.
- The login limits attempts per minute and per hour. The limit applies before the password check, not after it.
- Outbound mail counts as healthy when it is configured and fewer than ten deliveries failed in the last hour — without it no incident report reaches you.
- The database schema is held against a fixed list of tables, columns and indexes. A missing piece is reported as a migration that has not run, not as a data error.
- Alerts are deduplicated: the same key increments a counter and resets the acknowledgement instead of producing a second email.
The state is measured from nine parts: database, cache, storage, queue, schedule, daemon, outbound mail, model access and schema. The run also measures its own duration — a measurement that itself takes too long is a finding about the installation, not only about what it measured.
What is not listed here is not measured either. A statement about the availability of your own website is not part of it: if your page does not load, neither does the widget, and at this point that is not a finding about XICBOT.
The state of the operation on one page
-
Key figures for the last seven days and conversations per day sit side by side.
-
What is set up stands as a list next to them.
-
The most recent conversations sit below the numbers, not in a second area.
What happens during an incident
The order below is the one the system works in, not the one in which we hear about it. Detection comes from the measurement; your report is the second path, not the first.
An incident is not always an outage. Answering more slowly, reading sources late and not appearing at all are three different situations with three different consequences — the second is usually invisible from outside and still a finding.
-
Detect
Monitoring runs without interruption and checks at short intervals. An incident is detected by the measurement itself, not by someone reporting it.
-
Classify
We distinguish degradation from outage: if the assistant answers more slowly, that is a degradation; if it does not appear or does not answer at all, that is an outage. The classification determines the channel and the speed of the report.
-
Absorb
Before an alert has even been written, the visitor already has the incident in front of them. So the frame decides for itself: configuration not loadable means locked input with the reason in the status line; a language model failure mid-answer means the half-written text is discarded and the stored fallback answer is sent. The visitor reads a sentence in the flow of the conversation, not an error code.
-
Report
An outage is reported to the address stored in the account, with what is known: affected part, start, impact. A report without a known cause is better than no report.
-
Catch up
During and after the incident the queue catches up. A job has three attempts, the daemon reclaims orphaned jobs on start, and whatever finally fails does not simply sit there but raises a critical alert of its own. A source read can therefore arrive late, but complete.
-
Fix and follow up
After the fix we add what the cause was and what has been changed so it does not repeat. Changes that come out of it appear in the changelog.
What is not stated here: a deadline by which an incident is resolved. We do not name one, because we cannot measure it before we know the cause. What we commit to instead is the report itself — including when the cause is still open at the time of reporting.
You can switch the assistant off yourself at any time without waiting for us. The widget switch applies from the next request to every embed of that assistant; the page stays, the chat disappears.
Maintenance and planned work
Work that may cause an interruption is announced beforehand and scheduled for times of low usage. The announcement goes to the address stored in the account and names the time window and the affected part. Changes that can be delivered without interruption are not announced individually but recorded in the changelog.
What you can check yourself
- Does the widget appear on your page? If not, first check whether the snippet is still in the template and whether the domain is listed among the permitted domains.
- Does the assistant answer in the test area of your account? If it does but not on the website, the cause is the embedding, not the service.
- Does a source under Knowledge show “not indexed” or “outdated”? Then the assistant lacks the current state of that source.
- Are the package quotas for the current month exhausted? Then the assistant answers in a limited way without there being an incident.
- Was a source removed or a tool switched off recently? The audit log shows it with timestamp and the account that triggered it.
Frequent questions about status and incidents
The questions here concern day-to-day operation. How to check in your account which part is currently stuck is described in the documentation; what changed in a release is in the changelog.
Why does this page not show a current state?
Because a static page cannot measure it. It would show a state frozen at build time — wrong precisely during an incident, when it matters. The measured state is in your account under Operations, with the timestamp of the measurement. Nine parts are checked: database, cache, storage, queue, schedule, background service, outgoing mail, model access and schema. Not measured is reported there as “unknown" and not as “fine" — a failed probe does not overwrite the last success. The same information is available publicly without a login; anything other than normal operation answers with an error code, so monitoring detects the disruption without parsing any text.
How do I learn about an incident?
Not by email, but by measurement. Monitoring covers nine state parts and one heartbeat per schedule entry; an overdue heartbeat is recorded as a critical alert. A public state endpoint is reachable without a login and answers anything other than normal operation with code 503, so that even a monitor reading nothing but the code sees the incident. Not measured is stated there explicitly as unknown and not as healthy: a failed measurement is not booked as a green result. Outward, the endpoint names no error texts, no table names and no host names. What is monitored and what happens during maintenance is described under status.
What happens to conversations held during an incident?
Conversations that have started are kept and can be reviewed afterwards under Conversations. If the model fails, the visitor does not get an error code but the stored fallback reply; the conversation does not break off, it ends with a note and the way to a human. An empty knowledge base is kept apart from an outage: a different sentence to the visitor, a different record, a different signal — otherwise an empty knowledge base would look like a fault. What the assistant could not take in during that time does not appear later; this is why every incident report names the affected period. The current state is shown on the status page, where a failed measurement counts as a fault and not as a success.
Does an incident affect my website?
As a rule, no. The widget does not sit in your page's critical path. The loader is a single self-contained file that triggers no network call of its own; the frame is only built after your page has fully loaded, plus one further tick, in its own origin with no access to your document. If the service fails, the assistant is missing while your page is delivered unchanged; the frame then shows a plain sentence instead of an error code. Nine parts are measured — database, cache, storage, queue, scheduler, daemon, outgoing mail, model access and schema. Anything other than operational is answered by the public status endpoint with 503. The status page shows the current state.
Can I switch the assistant off during an incident?
Yes. In the Assistants area you can pause delivery without removing the snippet from the template. That is the fastest route if the assistant should not appear on the page. A paused assistant behaves outwardly like an unknown or switched-off one: the response is the same in all three cases, so nothing about your key can be read from it. Without the script your page stays unchanged — the assistant sits in its own area and does not interfere with your layout. You use the same switch the other way round during setup: a newly created assistant is a draft and only answers once you set it active.
Is there an availability commitment?
No, and the built state records that as a decision: there is neither a commitment in per cent nor an announced maintenance period nor a promise about response times. What does exist is measurement. Nine parts are checked — database, cache, storage, queue, scheduler, daemon, outgoing mail, model access and schema; anything other than operational is answered by the public status endpoint with 503. The queue counts as healthy as long as the oldest open job is young enough and few runs failed within the last hour; model access is checked via key and port, not through a model call. The status page shows the history, the plans are listed under pricing.
One question comes up regularly and has an uncomfortable answer: no, there is no committed availability figure. What we state instead is what is measured, at what interval, and what happens when a measurement fails. A number nobody can recalculate would be worth less here than a description of the measurement.
Overview
Rather look at the state in your account?
The overview shows the key figures for the last seven days, conversations per day, what is set up and the most recent conversations. Your package consumption in the current month is under Billing. Go to the overview in your account
Is something not working as expected?
Describe briefly what you see and name the affected website URL and the approximate time. Both help to trace the measurement at the time of your observation. By phone you can reach us at +49 5123 9579000.