plexivo
Sign inContact sales

Reliability

Proof,
not promises.

Every month we run recovery drills on production. A published result stays current for 45 days, with re-verification due after 30.

View the latest reportAll drills

The Freeze Doctrine, tested

The Plexivo console and API went dark for 15 minutes.
Your apps never noticed.

We cut the Plexivo console and API off from a production site on purpose. Every app request was answered, and every connection rejoined the moment they returned.

  • 15 minConsole and API offline
  • 5,780App requests served
  • 0Requests failed

Measured . What pauses is only the Plexivo console and API: new deploys, console actions, Plexivo AI and the app-backend APIs (Auth, Data API, Realtime, GraphQL and Functions) wait until they return, then resume on their own. Read the report

Latest verification

Latest verification

Whole site lost: Plexivo detected it and rebuilt it automatically

Pass
7 min 4 sMeasured recovery

One controlled test. Its measured outcome, not a promise for every incident.

Customer impact
App answering 383 s after the loss
Detection time
1 min 30 s
Recovery time
7 min 4 s
Recovery point
0 s
Data consistency
Pass
Data integrity
Verified
Application verification
Pass
Last verified Verified · 11 days ago
Read the full report

Tested where it matters.

Measured outcomes for the products you run. Open a product to see its test and date.

Plexivo App Runner

Recovered after its only instance stopped.

What we measured for App Runner

Stopping the only instance produced 6 errors in 1,217 requests. The longest observed request interruption was 1.29 seconds.

Measured (IST)

Plexivo Postgres

Your data, restored to the chosen second.

What we measured for PostgreSQL

The restored database was running after 102 seconds, holding exactly the rows written before the recovery point.

Measured (UTC)

Plexivo MySQL

Backed up and restored in minutes.

What we measured for MySQL

An on-demand backup completed in 78 seconds. A point-in-time restore was running and answering after 321 seconds.

Measured (UTC)

Plexivo Cache

Twice the memory, still answering.

What we measured for Cache

The cache grew from 512 MB to 1,024 MB and was answering over TLS 200 seconds later. After a restart it was ready again in 1.2 seconds.

Measured (UTC)

Plexivo Kubernetes

Deployed in seconds. Scaled in seconds.

What we measured for Kubernetes

The workload was running after 11 seconds and scaled to three pods after 17 seconds.

Measured (UTC)

Network access

Only the addresses you trust.

What we measured for Network access

A trusted-IP list took effect in 16 seconds; private databases stayed reachable through the Plexivo CLI tunnel.

Measured (UTC)

Measured in controlled production tests on the dates shown. Times vary with data size and configuration.

How we verify reliability

Recovery,
rehearsed monthly.

Thirteen steps from a deliberate failure to a published result. Future drill times are not published.

  1. 01
    Select the scenarioOne major failure or recovery path per cycle.
  2. 02
    Prepare the drillProduction-equivalent workloads and pass criteria, agreed in advance.
  3. 03
    Trigger the scenarioDeliberately, in a controlled window.
  4. 04
    Observe the platformDetection, fencing and alerts, as they happen.
  5. 05
    RecoverUsing the documented procedure — nothing improvised.
  6. 06
    Verify applicationsHealth checks from outside, against real endpoints.
  7. 07
    Verify dataCommitted data compared before and after.
  8. 08
    Verify correctnessNo duplicate operations, billing or conflicting authority.
  9. 09
    Measure RTO and RPOHow long recovery took, and how much data was at risk.
  10. 10
    Record the evidenceTimestamps, graphs and check results.
  11. 11
    Engineering reviewWhat behaved differently from expectation, and why.
  12. 12
    SanitizeAddresses, hosts and mechanisms stay internal.
  13. 13
    PublishA passed drill goes public; anything else is fixed and re-tested first.

What we test

Ten ways
things go wrong.

Each cycle picks one. Over time, every recovery path gets exercised — and re-exercised after anything changes.

  • Console and API offline

    Customer workloads keep running normally while the Plexivo console and API are offline.

    Platform

  • Compute recovery

    Workloads recover on their own when the compute capacity under them is suddenly withdrawn.

    Recovery

  • Database recovery

    Database availability, recovery, data consistency and application connectivity.

    Database

  • Backup restore

    A production-equivalent workload restored entirely from protected backups, then verified.

    Backup

  • Point-in-time recovery

    Protected data recovered to a known historical point and checked for consistency.

    Backup

  • Regional recovery

    A primary operating region taken out of service, and the regional recovery procedure exercised.

    Regional

  • Console and API relocation

    The Plexivo console and API moved to alternate infrastructure, then checked end to end.

    Platform

  • Network partition

    Partial network isolation, verifying that conflicting authority and unsafe changes are prevented.

    Network

  • Compound recovery

    Several events at once, verifying graceful degradation and full recovery.

    Recovery

  • Backup path resilience

    Recovery protections keep working when one storage or backup path is taken away.

    Backup

Latest results

Every drill,
its latest result.

One line per drill. Each report keeps the earlier timings.

The latest passed result of each reliability drill
DateScenarioCategoryResultMeasured recoveryReport
Enterprise region lost: Plexivo detected it and rebuilt everything in a second region Regional PassRe-verification in progress (new build) 8 min 43 s View report
Whole site lost: Plexivo detected it and rebuilt it automatically Recovery PassVerified · 11 days ago 7 min 4 s View report
Single application instance restarted Recovery PassVerified · 14 days ago 1.3 s View report
Plexivo console and API offline for fifteen minutes Platform PassVerified · 14 days ago — View report
Server powered off under a high-availability database Database PassVerified · 14 days ago 1 min 21 s View report
Edge proxy failure Network PassVerified · 14 days ago 0.4 s View report
Cache instance restarted Database PassVerified · 18 days ago 1.2 s View report
MySQL point-in-time recovery Backup PassVerified · 18 days ago 5 min 21 s View report
PostgreSQL point-in-time recovery Backup PassVerified · 18 days ago 1 min 42 s View report
A full day of steady use Platform PassVerified · 18 days ago — View report
Whole hosting site stopped and started Recovery PassVerified · 19 days ago 6 min 23 s View report
Application instance failure Recovery PassVerified · 19 days ago 0 s View report
High-availability database failover Database PassVerified · 19 days ago 6.2 s View report
Database process failure Database PassVerified · 19 days ago 1 min 11 s View report
Machine lost under a single-instance database Recovery PassVerified · 19 days ago 3 min 1 s View report
Platform agent failure Platform PassVerified · 19 days ago 2.1 s View report

How to read
a report.

RTO

Recovery time

How long recovery took, from the failure to customers being served again. Always a measured value.

RPO

Recovery point

How recent the recovered data is. Zero means every committed write was kept.

Detection

Detection time

How long it took to notice the failure, from the moment it began. Shown whenever it was measured.

Scope

Exactly what was tested

Every report states its scenario, release and configuration, so each result means precisely what it says.

The uptime guarantee

A written commitment with service credits, set out in the SLA and separate from drill results.

Read the SLA
A drill

Engineering evidence that a recovery path works, measured in a controlled test.

Rehearsed. Measured.
Published.

Run on a platform that proves its recovery.

Start free trialRead the uptime SLA