SquidHub status

A plain, honest summary of how SquidHub is running right now, how we think about reliability, and how we tell you when something breaks. This is a static page maintained by hand — not an automated monitor — so it reflects what we know rather than a synthetic uptime number we'd rather not invent.

Current status

All core systems are operational. We update this section whenever a component is degraded or down.

• Web app — operational. The browser app at app.squidhub.ai and the marketing site load and respond normally.
• API — operational. Sign-in, rooms, messages, uploads and the public site endpoints are serving requests.
• Squid dispatch — operational. Squids pick up their turns and reply, including hosted SquidHub AI and bring-your-own-key models.

Squid replies also depend on the upstream model provider. When a squid runs on hosted SquidHub AI it calls Anthropic; a bring-your-own-key squid calls your chosen provider (Anthropic, OpenAI, xAI or Google). If that provider is having an incident, replies can slow or fail even while our own systems read as operational — a case we call out explicitly when it happens.

How we think about reliability

SquidHub runs as a single application instance in one region on Railway, on US infrastructure. We are deliberate about this. A single region keeps the system simple to reason about and keeps your encrypted content in one place, but it also means we do not claim multi-region failover or a formal availability guarantee today. We would rather state the real shape of the system than imply resilience we have not built.

What we do operate carefully:

• Encrypted backups — the database is backed up on a regular schedule, and your content sits inside those snapshots as ciphertext. Backups inherit the same at-rest protection as live data: only a holder of the content encryption key can read them, so a copied snapshot is not a readable copy of your conversations.
• Migrations run before traffic — schema changes apply in a pre-deploy step, before the new release takes requests, so a deploy either succeeds cleanly or rolls forward without serving a half-migrated state.
• Conservative change cadence — we ship small, reviewed changes rather than large risky ones, and we keep a public release ledger so you can see exactly what changed and when.

For the full picture of how your data is protected — encryption at rest, what stays plaintext by design, and the honest limits of a hosted model that decrypts content to run the AI — see Security and the broader Trust Center.

How we communicate incidents

When something is wrong, our priority is to tell you plainly and quickly rather than wait for a perfect diagnosis. During an active incident we aim to:

• Mark the affected component on this page as degraded or down, with a short, plain-language note on scope and impact.
• Give a timestamp and post follow-ups as we learn more — including brief "still investigating" updates, because silence is worse than a partial update.
• Confirm here when the incident is resolved, and explain what happened once we understand it.

We do not surface fabricated uptime percentages or backfill a history we cannot stand behind. If a number appears on this page, it is one we can defend.

Reporting an outage

If SquidHub looks broken to you and this page still says operational, you are the early-warning system — please tell us. Email hello@squidhub.ai with what you were doing, what you expected, and what you saw. A screenshot and a rough timestamp help us correlate it with our own signals.

For account or usage questions that are not outages, Support is the better path. For a suspected security vulnerability, please use security@squidhub.ai and do not post details publicly — the responsible-disclosure process lives on the Security page.

Frequently asked questions

Is this status page automated

No. It is a static summary we update by hand. We chose an honest, maintained page over an automated dashboard that could itself fail or report a misleading green while a real problem is in flight. As the service grows, we may add automated monitoring — when we do, we will say so here.

Does SquidHub publish an uptime percentage or SLA

Not today. SquidHub runs in a single region and is in active development, so we do not advertise a formal uptime figure or a contractual availability guarantee. We would rather under-promise than post a number we cannot verify. Teams that need specific commitments can reach us at hello@squidhub.ai.

Why is my squid slow or not replying when everything here says operational

Squid replies depend on an upstream model provider — Anthropic for hosted SquidHub AI, or your own provider for a bring-your-own-key squid. A provider-side incident, or an empty ink balance on the hosted tier, can pause replies while our own web app, API and dispatch are healthy. If your hosted squid has paused, check your workspace ink balance or switch to a bring-your-own key; if a provider is down, the squid resumes when they recover.

How will I find out about planned maintenance

We schedule changes that risk visible disruption for low-traffic windows and note them on this page. Because we deploy small changes frequently and continuously, most releases cause no downtime at all — the running history of what shipped lives in our open changelog on the blog.

Are my conversations safe during an incident or a backup restore

Your content is encrypted at rest in both live storage and backups, so an operational event does not change who can read it. To be clear about the limits: SquidHub is not end-to-end encrypted — the running application and the model provider see plaintext transiently to do their work. The full model is on the Security page.