What happens when something breaks

Continuity is the part of a security page most vendors leave vague. This one gives you our recovery targets, the tier each service sits in, what is tested and what is not yet, and the specific things we have not built. It covers every product Alano Tech Pte. Ltd. operates.

What this covers

Alano Tech Pte. Ltd., incorporated in Singapore, operates a family of products. They share one legal entity, one set of security and continuity standards, and one governance cycle.

The recovery targets, service tiers and capacity controls below are written for the business platform — Alano CRM, Alano Marketing, the AI assistant and Omucloud. Intercam.ai and Japan Cat are consumer applications operated by the same entity under the same governance, and carry their own privacy and terms documentation; ask us if you need their continuity posture specifically.

Alano operates under group-level continuity and security governance. The framework on this page — how services are tiered, how recovery objectives are set, how incidents are graded and escalated, how vendors are overseen — is the group standard, applied to Alano's own infrastructure and its own numbers.

Every product listed above is bound by it. Where a product's specifics differ — a consumer app has a different processor set from the CRM, for instance — the difference is documented rather than smoothed over.

Which services matter most

Not everything deserves the same recovery effort. We tier each service by what its loss actually costs you — losing access to your own data, or missing an obligation we owe you, ranks above losing a convenience. Tier 0 is restored first and degraded last.

Consent and suppression are Tier 0 for Marketing for a specific reason: if that machinery is degraded, the correct behaviour is to stop sending, not to send without checking. We would rather delay a campaign than mail someone who opted out.

The AI assistant is deliberately Tier 0-free. If AI capacity is lost, your CRM keeps working — nothing about reading, editing or exporting your own data depends on a model being available.

Omucloud sits differently from the rest. Mail that has been accepted and then lost cannot be re-sent by anyone — there is no equivalent of restore-and-retry, because the sender has already had their delivery confirmed. Inbound receipt is therefore treated as the most loss-sensitive operation across all four products.

Recovery targets

RTO is how long we aim to take to restore a service. RPO is how much data we accept losing in the worst case. These are the group standard applied to Alano.

These are design targets, not tested results. We have not yet run a full failover exercise, so we describe them as what we build towards — not as a demonstrated capability, and not as a contractual guarantee.

The distinction matters, so here it is in full. Recovery from data-level failure — an accidental deletion, a corrupted table, a bad migration — is well within these targets, because it is a restore against a managed platform that supports point-in-time recovery. Recovery from the loss of an entire cloud region is a different problem: Alano runs in a single region today, so a regional failure would put us in a rebuild, and we will not claim a four-hour recovery for a scenario we have not exercised.

We would rather publish that gap than publish a number we could not defend in a security review. When a failover test has been run and recorded, this section will say so, with the date and the result.

Where Alano can run

Backups and restore

Across all four products:

• Backups run automatically on the managed platform, with point-in-time recovery available — the mechanism behind the 15-minute RPO target.
• Database and file storage are both covered; attachments and uploads are not left outside the backup regime.
• Restores are performed by the platform provider's tooling rather than a bespoke script, which is a deliberate choice — fewer moving parts of our own to fail at the worst moment.

What we have not done: a scheduled restore drill. Backups existing and backups being provably restorable are different claims, and only the first is currently true of Alano. Establishing a regular restore exercise is on the roadmap, and this page will carry the cadence and the date of the last drill once it is running.

Where it runs, and what that means

Alano runs in a single cloud region in Asia, on managed infrastructure — Supabase for database, authentication and storage, running on AWS. There is no cross-region replication or standby environment today.

What that gives you, and what it does not:

• Within the region, the managed platform is fault-tolerant — individual machine failures are absorbed without our involvement.
• Data is backed up continuously, so failures that corrupt or delete data are recoverable.
• A full regional outage would take Alano down for the duration of that outage. We would not be able to fail over to another region within our stated RTO today, and we are not going to imply otherwise.
• Single-region also means your data is not being copied across jurisdictions behind your back. Where it sits is where it stays.

If your organisation needs a specific region, cross-region resilience, or infrastructure inside your own network, that is a deployment conversation rather than a setting — Alano can be delivered as a dedicated project or built to run entirely inside your environment.

Compare the deployment options

Capacity and abuse controls

Capacity controls exist so that one workspace's traffic — or one bad actor's — cannot degrade the service for everyone else.

• Alano CRM: Public API endpoints are rate limited per organization, with IP reputation tracking, block windows, and an optional allowlist for the addresses you expect traffic from.
• Alano Marketing: Sending is paced by deliverability controls, and consent and suppression are checked on every send rather than at campaign build time.
• Alano AI Assistant: AI actions carry a per-workspace monthly allocation, which doubles as a natural ceiling on the cost and load a single workspace can generate.
• Omucloud: Domain ownership must be verified by DNS before any address on it can send or receive, which is the primary control against the service being used as an open relay.

The group framework sets graduated capacity alerting — early warning well before saturation rather than discovering a limit by hitting it. Alano's monitoring against those thresholds is being built out; we are not yet in a position to publish headroom figures, and we would rather say that than quote a number we do not measure.

Availability

Alano targets 99.9% monthly availability for Tier 0 services. That is an internal objective we hold ourselves to, not a contractual guarantee attached to the free tier. Where a contractual SLA is required, it is agreed as part of an enterprise agreement.

We do not currently operate a public status page. It is the single most common thing enterprise reviewers ask us for that we do not yet have, so we are stating it plainly rather than leaving it to be discovered. Until one exists, service-affecting incidents are communicated directly to affected customers.

When something goes wrong

Incidents are graded on a standard four-level severity scale. The grade determines who is woken up, how fast we communicate, and whether the incident is reviewed afterwards.

What we commit to:

• If an incident affects your data or your access to it, we tell you directly — we do not wait for you to notice.
• Where a personal data breach has occurred, we notify the relevant supervisory authority within 72 hours of becoming aware of it, as GDPR requires, and we notify affected individuals where the breach is likely to result in a high risk to them.
• SEV1 and SEV2 incidents get a post-incident review covering what happened, why, and what changes as a result. Affected customers can request it.
• Changes made inside your workspace during an incident land in its audit log the same as any other change, so there is a record you can read yourself.

Alano does not currently run a formal 24/7 on-call rotation, and we are not going to describe our coverage hours as something they are not. If you need a defined response-time commitment, it belongs in an enterprise agreement where it can be written down and meant.

Report a vulnerability

Change without breakage

Most outages at any software company are self-inflicted — a deployment, not a disaster. The group framework requires that changes to critical services carry a continuity assessment before they ship and a way back if they misbehave.

• Application deployments are versioned and revertible — a bad release is rolled back rather than fixed forward under pressure.
• Database migrations are reviewed before they run, and destructive changes are treated as a different class of change from additive ones.
• Point-in-time recovery covers the case a migration gets through review and still causes damage.

The vendors we depend on

Alano's continuity is bounded by its providers' continuity. Being honest about that is more useful than implying we are independent of them.

• Supabase (on AWS): Database, authentication and file storage for the CRM and Marketing. A sustained Supabase outage in our region is an Alano outage. They hold SOC 2 Type II and ISO/IEC 27001:2022 and publish their own status and incident history.
• Vercel: Hosting and delivery for the web applications. Loss of Vercel affects reachability, not the integrity of stored data.
• OpenAI: Powers the AI features. An OpenAI outage disables AI actions and nothing else — by design, no Tier 0 function depends on it.
• Resend: Transactional email. Loss delays notifications and sign-in codes; Google sign-in remains available as an alternative route in.

None of these currently has a tested alternate that we could switch to under pressure. Concentration on a single infrastructure provider is the largest single continuity risk Alano carries, and it is reviewed as part of the group governance cycle rather than treated as settled.

The full sub-processor list

Who owns this

Continuity for every Alano product is owned at CEO level, with the group CTO owning the policy framework itself. Alano is a small company and we are not going to draw an org chart with more boxes than people in it — but ownership is explicit, and it does not move.

The governance cycle:

• This policy and its recovery objectives are reviewed at least annually, and after any material incident or significant change to the architecture.
• Recovery objectives, incident records and change history are retained as evidence, and can be provided to enterprise customers under NDA.
• Assurance today is self-attested. There is no independent audit of Alano's own controls — see below.

What we have not built yet

Every item below is something an enterprise reviewer will ask about and we would have to answer no. Publishing the list ourselves is less comfortable than letting it come up in a call, and considerably more useful to you.

• No tested disaster recovery: A full failover exercise has not been run. Our recovery targets are design targets, not demonstrated results.
• No restore drill cadence: Backups and point-in-time recovery are in place. A scheduled exercise proving a restore end to end is not.
• Single region, no standby: A regional outage would take Alano down for its duration. Cross-region resilience is available through a dedicated deployment, not on the shared cloud.
• No public status page: Incidents are communicated directly to affected customers. There is no self-serve page to check.
• No enforced MFA, no cloud SSO: Signing in with Google carries whatever 2FA is on your Google account, but Alano cannot require MFA across a workspace and offers no second factor of its own. SAML and OIDC are available in a dedicated or on-premise deployment only.
• No SOC 2, no penetration test: Our infrastructure provider is certified; Alano is not. SOC 2 is on the roadmap with no auditor engaged and no date we would ask you to rely on. No third-party penetration test has been conducted.

We will say each of these is done when it is done, with a date — and not one sentence before.

How signing in works today

Overview | Architecture | Deployment | Compliance & privacy | Privacy Policy | Chrome Extension Security | Contact