Status Security, Service and Support Policy
Security responsibilities, research reporting, operational coverage, maintenance, support, and SLA remedies for Status.
Last revised: October 23, 2026
This Security, Service and Support Policy ("Policy") forms part of the accepted Status agreement to the extent incorporated by its Terms of Service. An accepted service-level agreement ("SLA") or support schedule establishes any additional measurable commitment and remedy. The express reasonable-skill-and-care obligation and remedies for uncured material failure remain applicable. An operational target constitutes a binding service-credit commitment only when the accepted SLA expressly gives it that effect.
Security responsibilities
Solarius maintains risk-appropriate authorization, privileged-access, tenant-boundary, vulnerability, change, logging, and contracted recovery controls for components it operates. Customer users, configuration, keys, local hosts, persistence, and independently selected providers remain in their actual operator's scope. Enabling an edge or hosted function adds only its stated processing boundary. Status's platform console cannot reveal monitor targets or credentials, incident narratives, subscriber addresses, or impersonate a customer; authenticated service components still process the data needed to deliver Status.
An encryption feature is not a claim of universal certification, zero-knowledge architecture, or end-to-end encryption. Required personal-data safeguards and incident duties follow the DPA, including its supplier and transfer provisions.
Research and incident reporting
The Solarius security and bug bounty policy supplies the common reporting, testing authorization, exclusions, reward, disclosure, update, and incident rules. Send vulnerabilities to bugs@solarius.me with minimal redacted proof; do not include credentials or unrelated customer records. Prohibited methods and ineligible reports also apply to Status.
Active compromise or material operational impact requires help@solarius.me and the purchased urgent channel. Do not wait for research triage. A finding in a customer's workload is distinct from a vulnerability in Status; customer testing permission does not authorize testing shared Solarius systems.
Product scope and targets
Status Standard support covers the contracted monitoring, coordination, publication, and notification service. Optional Priority Support applies only under the purchased package. No universal numeric response time or uptime percentage is created by the base subscription or this policy.
Your agents, target systems, DNS, identity provider, mail or webhook receivers, on-call availability, and independently selected infrastructure affect results and delivery. A queued check, accepted webhook, sent email, or browser push handoff does not establish that a human received and acted on a notice. An SLO or customer-generated uptime report is separate from an SLA purchased from Solarius.
Cloud platform administration preserves the documented separation between platform staff and tenant content. Shared database recovery has instance-wide effects; per-organization portability uses export/import rather than selective database restoration. Self-hosted operators administer updates, persistence, encryption keys, workers, mail, and their backup/restore testing. See operability and cloud platform policy.
Requesting support and escalating an incident
Use help@solarius.me or the support route named in your order. For purchased urgent coverage, use the escalation contact in that agreement rather than relying on an unattended ordinary email thread. Include the organization, product and deployment type, affected resource IDs, UTC start time, observed impact, operation or request references, and a reachable responder. Remove passwords, tokens, and unrelated customer content.
Solarius shall assess and administer support severity by reference to the actual impact and urgency of the reported condition, within the contracted coverage. A production-wide outage or active material security incident takes priority over a cosmetic defect; the assigned severity and any change should be explained. Supply reasonable diagnostic information and provide a person authorized to approve changes. A support request authorizes only the investigation and assistance within its lawful scope. It shall not constitute consent to unrelated destructive operations, expansion of an approved response mandate, or unrestricted access to Customer Data. Additional approval shall be obtained where required by the product permissions or Agreement.
Initial response means a substantive acknowledgment and an assigned next step. It is separate from workaround, containment, remediation, restoration, and root-cause report. A proposed action or successful delivery to an external ticketing system is not evidence that its executor completed it. Solarius communicates material progress, blockers, and next steps within the agreed coverage.
Maintenance and changes
Solarius plans maintenance to reduce disruption, communicates expected material impact through the applicable service channel, and uses reasonable notice for scheduled work. Urgent security, legal, or reliability work can require immediate action and a prompt explanation. Customer approvals and change windows apply to the operations for which the product or agreement requires them.
Solarius does not retrospectively create a maintenance window merely to make an otherwise valid outage claim disappear. A planned retirement of core functionality follows the notice and remedy provisions in the Terms. Optional integrations and third-party components can change independently; Solarius explains material effects on the contracted service and any supported alternative.
Contractual availability and credit claims
A binding availability commitment must identify the covered service and region, measurement point, time zone and interval, successful-service definition, treatment of partial failures and unknown periods, permitted maintenance exclusions, and credit schedule. A customer-generated report or a public status page does not supply these missing contract terms. Solarius does not publish a universal uptime percentage or credit amount for all Status deployments through this policy.
Where an SLA exists, use its claim process and time limits. Provide the service, period, impact, and available evidence. Solarius compares relevant records and explains acceptance or rejection. Solarius shall not require a report format you could not reasonably obtain. A customer configuration or external-provider failure is excluded only to the extent it actually caused the affected failure under the applicable SLA; it does not excuse an independent service failure by Solarius.
Service credits and other remedies follow the agreement and mandatory law. An SLA credit provision shall not, by implication, exclude statutory data-protection remedies, mandatory rights, or the Agreement's express material-breach remedy. Any exclusive-remedy provision applies only to the extent expressly accepted and legally enforceable. The billing policy distinguishes account credits from cash refunds and prevents duplicate recovery for the same loss.
Customer continuity and assurance
Maintain the backup, alternative communications, routing, and recovery measures appropriate to your business. Tell Solarius about a required recovery point, recovery time, regulated workload, local processing boundary, or additional support need before relying on it. An agreement must confirm a requested additional commitment; a feature setting or sales conversation alone does not establish one.
Security and compliance materials are available through the contracted review process or legal@solarius.me, with reasonable confidentiality. Solarius provides the scope and date of evidence actually held and distinguishes operating controls from independent assurance. A product report is not itself a certification of your organization.