Trust & Security

1. The short version

IsItStillUp is operated by Nancy Sahu. It is a small team, and the honest summary of our security posture is: a simple architecture with a small number of moving parts, isolation enforced by the database rather than by application code remembering to filter, no passwords anywhere, and an audit trail that cannot disagree with reality because it is written in the same transaction as the change.

The section a reviewer should read most carefully is known weaknesses, which is on this page rather than absent from it.

2. Answers to the usual questions

If you are working through a questionnaire, most of it is here. Anything not covered, ask us and you will get a direct answer including “no” where that is the answer.

3. Tenant isolation

Every table that holds customer data has Postgres row-level security enabled, with a policy gated on a per-transaction session variable. Application code cannot reach another organisation’s rows by forgetting a WHERE clause, because the database will not return them.

The important property is the failure direction. A query run outside an organisation context matches neither branch of the policy, so it returns zero rows rather than every row. A bug in our code produces an empty page, which someone notices, rather than a cross-tenant leak, which nobody does.

There are exactly two ways to run a query in this codebase — one that sets an organisation context, and one system-level path reserved for the rendering pipeline, background workers, public page lookups and webhook ingestion. That is a rule we enforce in review, and the database is the backstop for when review misses one.

4. Authentication and access

• There are no passwords. Not hashed, not salted — none. Sign-in is a single-use link emailed to you, valid for 15 minutes, or your own identity provider over SAML. There is no password database to breach, no credential stuffing, and no password reset flow to attack.
• Sessions are 256-bit random tokens in an httpOnly cookie. Every dashboard page and action re-verifies the session on the server; the middleware’s cookie check is a fast path, never the authority. You can list your active sessions and revoke them, including everywhere at once.
• SAML SSO and SCIM for Okta, Entra, OneLogin and JumpCloud, with IdP groups mapped to roles. An organisation can require SSO, which switches off magic-link sign-in for its members entirely. Roles driven from your IdP are capped below ownership, so a directory misconfiguration cannot hand someone your organisation.
• API keys are stored only as SHA-256 hashes with a short display prefix. The secret is shown once, at creation, and is not recoverable — if you lose it, you rotate it.
• Roles — owner, admin, responder, viewer — on every plan including Free, enforced server-side on every mutating action rather than by hiding buttons.

5. The public page, and why it survives our bad days

A status page that goes down with the platform it describes is the category’s standing joke. Ours is built so that it does not:

• Published pages are pre-rendered static HTML, written to object storage ahead of time.
• Storage is replicated across two regions, and reads fall back to the second one.
• It is served with cache headers a CDN honours. We have not yet put one in front of production— the design assumes it and the deployment does not have it turned on. Until we do, every request reaches our application, and the paragraph below about what a regional failure costs you is written for that reality rather than the intended one.
• There is no database on the request path for a published page, and no JavaScript required to read it. The machine-readable feeds are served from the same storage.

The practical consequence, stated precisely: our database can be entirely offline — the failure that takes most SaaS products down completely — and your customers still see your status page and its current state, because serving it does not consult the database at all. The access rules for a private page travel with the page as a signed record in storage, so a locked page stays locked during that outage rather than failing open. Our commitments are in the SLA, which promises the page a higher number than the dashboard for exactly this reason.

What keeps working with the database down: your page on our domain or your own, its localised variants, audience-specific views, the RSS, Atom and iCal feeds, the JSON API and the export bundle. What does not: the uptime-history and per-component uptime pages and the status badge, which are computed from the database on request; team-only pages, which cannot verify membership without it and so fail closed; and the first unlock of a password page, because the password hash is deliberately never written to storage — visitors who already unlocked keep reading. Every write — posting an update, subscribing, the dashboard, the API — needs the database. And a page that has never published once has nothing to serve.

The honest limit, and we would rather state it than let you discover it. Serving a page still requires our application to be running, and our application and database are in the same region. A failure confined to the database, the queue, the renderer or the dashboard leaves your page unaffected — that is the common case and it is the one this design buys you. But a failure of the whole region takes our application with it, and because no CDN is currently in front of production, your page becomes unavailable at that moment rather than coasting on cached copies.

Nor could you post a new update during either kind of outage: what stays up is the last published state. Both limits are in known weaknesses below, and both are things we intend to fix rather than reword.

6. Outbound requests, and why that matters here

This product fetches URLs you give it — that is what a monitor is. Any such system is a potential server-side request forgery vector: without a guard, a customer could point a monitor at an internal address and read the response back through the dashboard.

Every outbound request to a customer-supplied target — HTTP, keyword, TLS, TCP and DNS monitors, webhook and chat notifications, and custom-domain verification — refuses private, loopback, link-local, carrier-grade-NAT and unspecified addresses, in both IPv4 and IPv6, including the IPv4-mapped IPv6 forms that defeat naive implementations. Cloud instance metadata sits inside the blocked link-local range. Every redirect hop is re-checked, not just the first URL.

The addresses are pinned. This is the detail that separates a real guard from a decorative one. A common implementation resolves the hostname, checks the answer, and then hands the name to an HTTP client that resolves it a second time — so someone controlling the nameserver can answer once with a public address for the check and again with an internal one for the connection. Here the guard runs inside the single DNS resolution the connection itself uses, so there is no second lookup to poison. Certificates are still verified against the original hostname: pinning changes the address, never the identity.

Refusals do not leak what they refused. A blocked monitor reports the category (“that hostname resolves to a private address”) and never the address or DNS record we resolved. That matters more than it sounds: monitor failure messages can be published into auto-created incidents on a customer’s own public status page, so a chatty refusal would have turned a DNS monitor into a public internal-network enumerator.

Three outbound paths still use the ordinary HTTP client — the Statuspage importer, SMS delivery and CDN cache purging. All three talk to fixed vendor hostnames with no customer input, so there is nothing to rebind.

7. Backups and recovery

Three details we would rather state than have you assume. First, the dump is written as compressed newline-delimited JSON with a footer containing row counts, so a truncated upload is detectable rather than restoring quietly short. Second, a deployment with backups misconfigured fails the job loudly instead of appearing healthy — a silent backup failure is the classic way this goes wrong, and the dump also refuses to run at all if the schema grows a table that is in neither the include nor the exclude list.

Third, and most usefully for you: four tables are deliberately excluded — raw per-probe telemetry, the job queue, sign-in tokens and rate-limit counters. Your daily uptime and latency history is not in that list and is fully backed up, because it is maintained as its own rolled-up table rather than recomputed from raw probes. What a restore would actually lose is per-check forensic detail (which region, which status code, the error text), a few minutes of in-flight probe results, and heartbeat monitors’ last-ping timestamps.

What we do not yet claim: a regular tested-restore drill on a schedule we publish. We restore into a scratch database when we change the format, but we are not going to describe that as a formal DR programme, because it is not one yet.

8. Where your data is

One deployment: Central India for the application, database and primary page storage; Southeast Asia for the replicated page copies and backups. Subprocessors operate in their own regions, listed in the privacy policy.

We do not offer EU or US data residency today. If that is a hard requirement, we are not the right vendor for you yet, and we would rather say so on this page than after your evaluation. Transfers are covered by Standard Contractual Clauses under our DPA.

9. AI features and your data

AI is used for drafting incident updates and postmortems, translating published content, assembling a communications pack, and answering questions on your public page from your own published content. All of it runs through Anthropic’s API.

• Content is sent only when someone in your organisation uses one of those features. The single exception is the weekly digest, which is off unless you switch it on and then summarises your own week on a schedule — we would rather name it than let you find a scheduled AI call we described as never happening.
• Your content is not used to train models.
• Nothing is ever published by AI. Every draft lands in a text box for a person to edit and submit.
• An organisation owner can turn AI off entirely, and that switch is enforced at the single point every AI feature passes through — not re-implemented per feature, where one would eventually be missed.

10. Audit trail

Every state-changing operation writes an audit record — who, what, when, and the affected object — inside thesame database transaction as the change. The two cannot come apart: if the change commits the record commits, and if the record fails the change rolls back.

The log is available on every plan including Free, filterable in the dashboard, and exportable as CSV. Audit records are not deletable through the product by anyone, at any role.

Audit events can also be forwarded to a webhook of yours as they happen. That live stream covers most, but not all, of what the log records, and we would rather give you the list than a reassuring adjective.

Streamed today: incidents and their updates, components, status pages and page visibility, team membership, roles and ownership transfer, SSO and SCIM lifecycle events, API key creation and revocation, custom domains, audiences, subscriber management including CSV import and quarantine, billing plan changes, incident notes, incident templates, uptime corrections, and the organisation deletion lifecycle.

Not streamed yet: most settings-page changes, monitor creation and deletion, incident edits made through the REST API, asset uploads, translations, imports, and metrics changes. Those still land in the audit log itself — they simply do not reach your webhook.

If you are feeding a SIEM, build against the CSV export as the authoritative source and treat the webhook as a low-latency signal on top of it.

11. Requiring review before anything goes public

A status page is the one surface where a hasty sentence becomes a public commitment. An organisation can require that only an admin publishes — and unlike most such controls, this one has no back door.

We enforce it on every path that can make words public: the dashboard, the REST API, the MCP server used by agents, inbound alerts from your monitoring, and our own monitors opening an incident automatically. We say this specifically because the usual failure of an approval control is that someone wires up automation a year later and quietly routes around it.

What it deliberately does not do: automation never loses an incident. A monitor or an inbound alert still opens one, held as a draft for a person to review, rather than being discarded. And the control governs incidents, updates and announcements — not individual component status changes, which any responder can still set.

12. Visitor problem reports, and the line they do not cross

A status page can show an “I’m having issues” button. When a visitor presses it we add one to a daily counter for that page — the same shape as the view counter, and the only two numbers we keep about visitors. No address, no device, no record of who pressed it.

If reports spike well above a page’s own normal level, we alert its operator privately. If — and only if — that operator has opted in, the page also shows a quiet line saying visitors are reporting problems. It says reports, never that the service is down, because at that moment the operator has not said anything and we will not put words in their mouth.

The line it does not cross, stated as fact rather than intent: a visitor report cannot open an incident, cannot change a component’s status, and cannot send anything to that page’s subscribers. The code that evaluates reports imports nothing capable of doing any of those three things, and that is checked rather than promised.

It is off by default, the operator sets the sensitivity, and a page with very little traffic cannot be tripped by a handful of clicks — the threshold is relative to that page’s own baseline and also has an absolute floor beneath it, so a determined stranger pressing a button repeatedly achieves nothing.

13. Known weaknesses

The part of this page we would most want to read about someone else. These are real, current, and listed because you would find them anyway.

• No third-party certification. No SOC 2, no ISO 27001, no independent penetration test report. If your process requires one as a gate, we will fail that gate today.
• A very small team. Few people can reach production — a small blast radius — but it also means no separation of duties, and support is one time zone (see the SLA for what we actually commit to).
• Single region, for the application as well as the database — and no CDN in front of it yet. Rendered pages and backups are replicated to a second region, but the application that serves them and the live database are not, and production is not currently behind a CDN. So a prolonged regional failure means the dashboard is unavailable, we restore from backup with up to 24 hours of data loss in the worst case, and published pages go down with us rather than being served from cache. This is the single biggest gap between our architecture and our slogan. Putting a CDN in front is the cheapest part of closing it and it is the next thing we intend to do; we are not going to write the slogan as though it were already done.
• No break-glass publishing during our own outage. Your page stays up if our database is down, but you could not post a new update to it until we are back. We consider this the most significant gap in the product’s own story and it is the one we are least comfortable with.
• No data residency choice. As above.
• Audit webhook streaming does not yet cover everything. As described in section 10 — the log itself is complete, the live stream covers most of it.
• Uptime corrections are disclosed on the page, but not everywhere else yet. A corrected day is visibly marked on your public status page. The uptime JSON API, the status badge and the monthly report in your dashboard still return the raw measurement, so those two views genuinely disagree for a corrected month. The page is the disclosed one; we would rather say that than let you find it.
• No formal tested-restore schedule. As above.

14. Reporting a vulnerability

Email support@isitstillup.com with enough detail to reproduce. We aim to acknowledge within two business days and to keep you updated until it is resolved.

We do not run a paid bounty. We will credit you publicly if you would like, we will not threaten you for testing in good faith against your own organisation’s data, and we ask that you do not test against other customers’ pages or access data that is not yours. Give us reasonable time to fix an issue before publishing it.

15. Keeping this page honest

This page is dated at the top and lives in the same repository as the product, changed in the same commits that change the behaviour it describes. If you find a sentence here that is no longer true, that is a bug and we would like to hear about it as much as we would a security report.