Status
What is running, and what we commit to
One live check, run from your browser against this application. A plain statement of what is and is not deployed. And what is and is not promised about availability — no uptime SLA on a self-serve plan, and no uptime history yet, which this page says rather than rounds up.
Last updated: 2026-10-05
1
Live check
This runs when you load the page, in your browser, against this host. It is the only thing this page observes first-hand, and it is reported without interpretation.
Checked from your browser, just now
Requesting /api/health from this host.
2
What this page does not show
There is no uptime percentage on this page, and there will not be one until it has been measured. No availability history has been recorded for any Scienter service. The aggregator that would record it is written and is not running anywhere, so there is no ninety-day bar, no monthly figure and no incident history to publish. A number here would be invented, and an invented number on a status page is worse than an empty one.
A dedicated status application exists in this repository — per-service checks over seven subsystems, a ninety-day uptime bar, a markdown incident log and an RSS feed — and it is not deployed to any host. Rather than rebuild a second, competing version of it here, this page performs the one check it can honestly make and reports deployment posture for everything else. Deploying it is on the roadmap.
Two status surfaces that disagree would be worse than one that admits its scope, so this one states its scope: one live check, and posture for the rest.
3
Deployment posture
Below is not a live health check. It is what is and is not deployed, as of the date at the top of this page — a fact about the product rather than a reading from a probe. It is here because several surfaces on this site answer with a gap instead of a number, and this table is the reason why.
| Subsystem | Posture | What that means |
|---|---|---|
| Dashboard and public site | Deployed | Serving scienter.xyz. Every page that does not depend on the engine renders from committed data. Checked live above. |
| Bot webhooks (Telegram, Discord) | Deployed | Served by API routes on this deployment rather than by a separate bot host, so the endpoints answer wherever this app is deployed. The lookups they expose are served by the intelligence service below, so a bot that answers "not available yet" is reporting that row, not a broken bot. |
| Trading-research engine | Not deployed | The engine behind trader scorecards and signals is internal research and is not part of the product sold here, so no public surface is served from it. Rug checks, entity lookups and the other forensic reads come from the intelligence service below. |
| Intelligence service | Deployed | Deployed on our own server behind intel.scienter.xyz. Whether it is answering right now is the second row of the live check above, read from this application when you load the page. |
| Alpha Ledger (on-chain) | Not deployed | The AlphaLedger contract is written and covered by 28 Foundry tests. It has never been deployed to any network, so nothing on this site is anchored on-chain and the site says "published" rather than "verified". |
| Uptime recording | Not deployed | The health aggregator exists and runs nowhere, which is why this page publishes live checks and no history. The first measured month begins when it is running continuously. |
| Inbound mail | Deployed | The scienter.xyz zone publishes MX records (Cloudflare Email Routing), so mail to the domain is accepted and delivered rather than refused. Where a page still prints a notice beside a specific address, that address has not yet been confirmed by a test send. |
| Alerting and social posting | Shipped, switched off | Built and shipped switched off behind environment flags. Absent its variables nothing is loaded, nothing is sent, and no request leaves the origin. |
4
Availability: what is and is not promised
No uptime SLA is offered on a self-serve plan. That is clause 8 of the Terms of Service, and this page does not say anything different. We aim for continuous availability and do not guarantee it; nothing has been measured yet (section 2 says so), and a percentage promised before there is a way to check it would be marketing, not a commitment.
Free access carries no availability commitment, no support response time and no credits. It may be rate-limited, degraded or withdrawn without notice. Saying so is fairer than an unenforceable promise attached to a product nobody paid for.
Self-serve. Support: community. Where a paid feature is materially unavailable for an extended period, write to us and we will make it right, as the Terms say.
Self-serve, on the same availability terms as Analyst. What the plan adds is support and seats: email, 24h, and 5 seats.
Any availability commitment, credit mechanism and incident-communication path is set out in the signed agreement, which prevails over this page. None is offered by default. Support: email, 2h + dedicated slack.
5
How an incident is communicated
There is no incident history yet because there is no recorded operating history yet. The commitment, for when there is one:
- An incident is declared for degradation, not only for outage. A subsystem returning stale or partial data while still answering 200 is an incident. That failure mode is more common than a hard outage and easier to miss.
- A published number that turns out to be wrong is an incident too. Correctness incidents are logged and corrected in public on the same terms as availability ones. For a product whose output is a judgment about a named party, a wrong number is the more serious of the two.
- Post-incident notes name the cause. Including when the cause is us. The post-mortem on our own signal engine is the standing example of the register these are written in.
Report something that looks wrong to methodology@scienter.xyz, and a security vulnerability to the bug bounty programme instead.