Service Status
Recovery services need visible health. Arximus status reporting is designed to show the availability of the cloud API, dashboard, backup orchestration, verification services, restore services, storage, alert delivery, reporting, billing, and connector infrastructure.
Availability
When a service protects recovery, customers need more than a single green light. They need to know whether backups are running, restores are available, storage is healthy, alerts are delivering, and reports can be accessed.
The status page should become a public operational surface once production services launch.
Incident updates
Useful updates explain affected components, start time, customer impact, current state, mitigation, and next update timing.
That is the standard serious operators expect from a platform tied to recovery readiness.
Status components
Customers need component-level visibility, not one vague status light.
API
Service endpoints for dashboard, jobs, assets, entitlements, alerts, and reporting.
Backup
Backup job scheduling, execution coordination, queue health, and worker status.
Verify
Manifest checks, chunk checks, database checks, decryption tests, and readiness calculations.
Restore
Restore planning, restore execution, validation jobs, and assisted recovery support.
Storage
Object storage availability, region health, retention jobs, and storage access.
Alerts
Email alerts, webhooks, escalation paths, and alert delivery monitoring.
Status is part of trust.
A recovery platform must be transparent when core services are degraded.
Next step
Security policy, privacy, and subprocessors explain the broader operating model.