System status
Drawing engine did not answer its check.
These checks ran when this page was requested, and are reused for up to 60 seconds. Each line below says what its check actually did, so you can judge the light instead of trusting it.
- ApplicationAnswering
This page was generated by the application when you asked for it. That is the whole of what this line proves — it cannot report on a request it never received.
- DatabaseAnswering306 ms
A live query ran against the primary database on the same connection the signed-in app uses.
- File storageAnswering379 ms
An authenticated request reached the file store. It touches no customer file — an empty answer is a passing answer.
- Malware scanningAnswering436 ms
The malware scanner was asked to answer at its own address, with no credentials attached. A refusal is the passing answer: it shows the service is reachable and still closed to everyone but us. No file is sent, so this line reports on the service — not on the signature database, and not on any one upload.
- Drawing engineDegraded323 ms
The drawing-analysis service answered its own readiness endpoint. It sleeps when idle, so a first call after a quiet spell is slower than a warm one.
Sheet indexing, drawing search and dimension extraction run here. Viewing and marking up a drawing does not — that happens in your browser.
- Inbound emailAnswering20 ms
A configuration check only: it confirms the mail webhook has credentials to accept a delivery. It does not send or receive a test message, and we do not claim it does.
No history yet. We do not store past results, so this page shows the run above and nothing else — there is no chart here because there is no record to draw one from.
Recovery
What we would lose, and how long it would take.
The two numbers a security reviewer asks for are the recovery point and the recovery time. We publish a number where machinery produces one, and a sentence where it does not. One of these is currently a sentence.
Recovery point — how much work a restore could cost you
Our own encrypted database snapshot runs once every 24 hours. In the worst case, restoring from that snapshot alone loses up to 24 hours of work. Our managed database provider also offers point-in-time restore, which for a recent incident recovers far closer to the moment of failure — we do not publish its window as a commitment, because it is a provider plan setting and we will not print a number we have not fixed in writing. A separate automated check runs daily and goes further than asking whether the backup job finished: it reads the newest snapshot, fails if it is more than 36 hours old, confirms it decodes, and compares its row counts against the live database. An unreadable snapshot fails that check and pages a human, rather than being excused by it.
Recovery time — measured, and what the measurement does not cover
The first end-to-end drill ran on 5 August 2026 and passed: we pulled the encrypted copy from the second provider, decrypted it, restored it into a throwaway database, and compared it to production. Every check matched exactly — workspace, project, document, user and activity-log counts, and all 232 database access-control policies. The database restore itself took one second; the whole exercise, from fetching the copy to verifying it, took under five minutes. Two honest limits on that number. It is the time to restore the DATABASE, not to return the whole service to customers — provisioning and cut-over are not yet drilled. And it scales with size: the copy restored was small, and a larger one takes proportionally longer. We still publish no contractual recovery-time commitment, and the drill result is re-measured and re-published rather than assumed to hold.
A second copy, at a second provider
Snapshots used to live with the same provider as the files they would be restored alongside, which is a single point of failure we were not comfortable with. Since 5 August 2026 a scheduled job also copies the database to an independent provider, encrypted, and the drill above restored from that copy rather than the primary one — so the second copy is not merely written, it is the one we proved we can come back from. Two honest limits. The job runs on a single machine today, so a night it cannot run is a night without a fresh copy; moving it to a cloud scheduler is in progress. And the same job mirrors customer files, but that mirror does not yet cover every file, so we do not rely on it yet.
Why there is no uptime percentage on this page
We store no history of these checks, so an uptime percentage here would be a figure with no record behind it. Our terms carry no uptime commitment either, and we would rather say that plainly than publish a number we cannot show you the working for. When we keep history, it will appear on this page and the percentage will be computed from it.
For your security review
The proof is written down, and we will walk you through it.
Tenant isolation is enforced in the database itself, not only in application code: a tenant query that loses its context returns nothing rather than another customer's rows. We keep a runnable harness that demonstrates this — including what it does not prove — and we will run it in front of your reviewer. Ask us for the tenant-isolation proof at contact@plazatech.llc.
Our controls are built SOC 2-aligned, and our hosting and database providers publish SOC 2 Type 2 reports, but neuroBLDR is not itself SOC 2 certified. A Type 2 audit is on the roadmap, and we will not describe it as anything else until it is finished.
The published security overview, the sub-processor list and the data-retention terms live with our policies. Read the security overview.