Version 2026-07-28-v1
Service Status and Incident Communication
Last updated: 28 July 2026
This page is the public communication route for planned maintenance, materially visible service disruption, and closure summaries that HisaBooks decides should be communicated broadly. It is a communication surface, not a promise of automated real-time monitoring output.
1. What this page covers
| Surface | What may appear here |
|---|---|
| Public website and purchase routes | Marketing pages, start-free flow, public legal/trust pages, and purchase/onboarding routes when customer-facing communication is warranted. |
| Authenticated web workspace | Company sign-in, main workspace access, released billing/operations/HR routes, and customer-facing document/share flows when disruption is broad enough to justify public notice. |
| Third-party dependencies | Payment, email, SMS, browser/platform, or government-network dependencies may be mentioned when they materially affect customer use, even though HisaBooks does not control their recovery timelines. |
2. Status labels
| Label | Meaning |
|---|---|
| Operational update | A dated notice about a visible change, advisory, or issue that does not necessarily mean a major outage. |
| Scheduled maintenance | A planned change window that may affect availability, performance, or specific actions for a period of time. |
| Degraded service | A released customer-facing workflow is partially impaired, slower, or intermittently failing, but the whole platform is not fully unavailable. |
| Major incident | A broader disruption affecting core access or completion of important released workflows for multiple customers or counters. |
| Resolved | The incident or maintenance window has been closed and the notice is retained as a dated communication record. |
3. How public notices are published
- This page is the public incident-communication route for customer-facing notices that warrant broad communication.
- Not every tenant-specific, browser-specific, or local-configuration issue becomes a public status notice. Localized issues may still be handled directly through support.
- When a public notice is posted, it should include the date, affected surface, current label, short summary, and next expected update or closure note when practical.
- Resolved or completed notices should remain readable long enough to provide an operational record of what was communicated publicly.
4. Planned maintenance
When practical, planned maintenance notices should describe the affected surface, intended window, expected customer impact, and whether any merchant action is recommended before or after the window. Maintenance notices may also be reinforced through direct support replies, in-app notices, or email where appropriate.
Not every internal change requires a public maintenance notice. Public notice is generally reserved for work that could materially affect released customer-facing behavior.
5. Security and sensitive issues
- If the issue is a suspected vulnerability, unsafe access path, exposed token, tenant-isolation concern, or other security-sensitive matter, use the Responsible Disclosure Policy instead of ordinary support.
- If the issue is merchant-specific access loss, a configuration problem, or a suspected defect limited to one company environment, contact support directly even if no public notice is posted here.
For the formal security-reporting route, use the Responsible Disclosure Policy.
6. Contact routes
For ordinary product support, email support@hisabooks.com or use the public Contact Sales route when the issue is commercial or rollout-related. For support boundaries and response targets, read the Support and Service-Level Policy.
This page applies to public communication from AARK NETWORK PTE. LTD. operating HisaBooks and should be read together with the Security Overview and Country Availability and Statutory Feature Register.