Current operational status
API uptime (24h)
Health uptime (24h)
Live data from status.resistro.org — updated in real time, not cached by this page.
Trust model
Trust
This page defines the current operating promise for Resistro Cloud. Every public claim here maps directly to the approved promise matrix and should be read together with its explicit boundaries.
Plan-based Postgres backup baseline
Resistro Cloud backs up Postgres databases on a plan-based cadence for small self-managed Postgres setups in the defined ICP: daily on Solo and Starter, hourly from Business.
Scope: Configured backup cadence for supported self-managed Postgres setups. The agent asks for backup work on a 1h default interval on every plan; the active plan decides how often a backup is accepted — daily on Solo and Starter, hourly on Business and Pro.
Preconditions: The customer system must be reachable, correctly attached, technically compatible, and the configured backup interval must be allowed by the active plan.
Evidence: Running backup jobs, heartbeat monitoring, Prometheus metrics.
Customer expectation: In normal operation with the default agent setup, a new backup run is created roughly each day on Solo and Starter and roughly each hour on Business and Pro.
Not covered: Postgres point-in-time recovery is proven, but not a current product promise; no automated, continuous PITR guarantee across all customer databases and no guarantee across network, host, or customer-side failure.
MySQL/MariaDB as request-only boundary case
MySQL/MariaDB is not an equal primary fit. Resistro treats self-managed MySQL and MariaDB setups as a bounded request-only path without parity claims.
Scope: Bounded logical dump and restore path via the Resistro agent for individually reviewed self-managed MySQL and MariaDB databases.
Preconditions: The customer system must be reachable, correctly attached, technically compatible, and the configured backup interval must be allowed by the active plan.
Evidence: Production E2E on June 27, 2026 covered MySQL and MariaDB backup, encrypted upload, download, decrypt, restore, and checksum match.
Customer expectation: MySQL/MariaDB can be reviewed case by case; publicly it is not equal to the Postgres fit.
Not covered: No point-in-time recovery, no physical/native backup guarantee, no database-version migration, no MySQL/MariaDB parity, and no statement for managed database platforms.
AES-GCM encryption with customer-held key
Backup data is encrypted before storage with AES-GCM and the key stays on the customer side.
Scope: Encrypted backup storage without server-side plaintext access.
Preconditions: The customer must provide and manage the key correctly.
Evidence: Implemented encryption path; no server-side access to plaintext backup data.
Customer expectation: Backup data in the Resistro storage path is not stored unencrypted.
Not covered: No key recovery and no broader security guarantee beyond this storage-path claim.
Default storage path on Hetzner Germany/EU
The default storage path uses Hetzner data centers in Germany/EU; backups are stored encrypted.
Scope: Backup storage path through Hetzner infrastructure in Germany/EU.
Preconditions: The customer uses the standard Resistro storage path; custom storage architectures would need separate review.
Evidence: Current storage provider Hetzner Online GmbH; public privacy notices identify Hetzner as hosting provider.
Customer expectation: Storage location, encryption, AVV/TOMs, and subprocessors are documentable checks for customer use.
Not covered: No legal advice, no blanket privacy or risk-free claim, no promise about authority-access or third-country-transfer risks, no immunity from lawful authority requests, and no statement for customer-side third-party storage.
Daily restore test
Resistro runs a daily restore-path test as an operating check so the defined restore path does not silently break.
Scope: A daily operating check of the defined restore path.
Preconditions: Restore-test jobs must run as scheduled and the operating environment must be available.
Evidence: Scheduled restore-test job, monitoring, alerting on failure.
Customer expectation: Resistro regularly checks that the restore mechanism still works as designed.
Not covered: No daily full emergency validation of every customer database and no application-level consistency check.
Stale-backup alerting after roughly one day
Resistro alerts when monitoring sees no successful backup signal for longer than the current 28h stale threshold.
Scope: Backup-failure alerting based on heartbeat and monitoring data.
Preconditions: Heartbeat, monitoring, and alerting infrastructure must all be functioning.
Evidence: Alert rules, heartbeat checks, monitoring-based alerting.
Customer expectation: Silent backup failure should not remain unnoticed beyond roughly one day under the monitored path.
Not covered: No 24/7 support, no reaction-time guarantee, and no guarantee against outages outside the Resistro monitoring path.
Daily /healthz smoke test
Public product paths are checked daily for basic reachability.
Scope: A daily smoke test against the public health endpoint.
Preconditions: The infrastructure and health endpoint must be reachable.
Evidence: Daily smoke test against `/healthz`.
Customer expectation: Basic reachability of central public product paths is checked every day.
Not covered: No uptime guarantee and no comprehensive end-to-end guarantee for all customer functions.
Plan-based RPO
The target RPO in normal operation is around one day on Solo and Starter and around one hour on Business and Pro.
Scope: A target derived from the plan-based backup cadence and monitoring.
Preconditions: Backups need to run successfully without a longer disruption chain.
Evidence: Plan-based backup cadence plus monitoring, without hard guarantee language.
Customer expectation: Potential data loss in normal operation is bounded to roughly one day on Solo and Starter and roughly one hour on Business and Pro.
Not covered: No hard uptime or data-loss guarantee for failures between backup windows or during extended disruption.
Manual operator-assisted restore
Restore is a controlled manual operation with operator support, not a self-service workflow.
Scope: Manual restore handling when a valid backup exists and operational restore is possible.
Preconditions: A valid backup must exist and the restore can be carried out operationally.
Evidence: Restore process and daily restore-path test.
Customer expectation: Restore is a supervised operational process rather than a push-button action.
Not covered: No support guarantee, no fixed RTO, and no self-service restore portal.
Customer-triggered restore drills
Customers can trigger restore drills on demand to verify the restore path for their own databases.
Scope: On-demand drill triggering against the customer's own backup data.
Preconditions: A valid backup must exist for the selected database.
Evidence: Drill trigger endpoint, drill result logging, restore-evidence PDF generation.
Customer expectation: A restore drill verifies that the restore path works for the customer's data at the time of the drill.
Not covered: A drill is not a production restore and does not constitute a backup guarantee beyond the verified restore path.
Restore-evidence PDF
After a restore drill, Resistro generates a downloadable restore-evidence PDF documenting the result.
Scope: PDF export of drill result as audit evidence.
Preconditions: A restore drill must have been completed successfully.
Evidence: PDF generated from drill result data including timestamp, database, and outcome.
Customer expectation: The PDF provides structured evidence of a completed restore drill for internal review or customer evidence.
Not covered: Not a legal certification, not a compliance certificate, not production-restore evidence, and not a PITR promise.
Explicitly not covered
- Postgres point-in-time recovery is proven, but not a current product promise; no automated, continuous PITR guarantee across all customer databases
- No uptime guarantee with service credits
- No support response-time guarantee
- No database-version migration in the restore path
- No MySQL/MariaDB point-in-time recovery, physical/native backup guarantee, or parity promise today
- No statement for managed database platforms such as RDS or Supabase
- No hard requirements outside the defined ICP
- No legal advice on authority-access, privacy, or third-country-transfer assessments
Who runs this
Alexander Renz is a Linux administrator, the founder of Resistro Cloud, and a small business owner since April 28, 2026. He operates the infrastructure himself and keeps the public promise intentionally bounded to what is real in production today.
Next steps
Get started or dig deeper
Check setup fit, compare pricing, inspect live status, or review the legal documents that support the current offer.
Promise boundaries
If a statement is not represented on this page, it should not be read as part of the current promise.