Service Notices

This page sets out how SMSBite communicates planned maintenance, emergency maintenance, incidents and material service changes, and how a customer raises an incident with us. It is the operational counterpart to the SLA: the SLA defines the commitments, this page defines how you hear about them.

Notices are delivered by email directly to the account contacts on record for your organisation, so that the people who need to act are told rather than left to check a page. Keeping those contacts current and monitored is your responsibility — a notice sent to an address you no longer read is still a notice given. Contact changes go to sales@smsbite.com.

Defined terms used below carry the meaning given in the Service Level Agreement and the Terms of Service. Where this page and the SLA differ, the SLA governs.

Scheduled Maintenance is notified to account contacts by email at least five (5) Business Days in advance and, save in exceptional cases, is carried out inside the standard maintenance window of 18:00–22:00 UTC on Saturdays and Sundays. “Business Day” has the meaning given in the SLA.

Notices go to the account contacts on record and state the planned start and end times in UTC, the components affected and the expected impact. If work is cancelled or runs beyond the notified window, a follow-up notice goes to the same contacts.

Maintenance carried out in the notified window is Excluded Downtime under the SLA: it is not counted as Downtime and does not give rise to a Service Credit.

Emergency Maintenance may be performed without advance notice where needed to preserve the security, integrity or stability of the platform, or to comply with an operator, regulator or law-enforcement instruction — for example patching an actively exploitable vulnerability or isolating abusive traffic.

Where advance notice is not possible we notify account contacts as soon as practicable, and in any event once the platform is stable, stating what was done and the period affected. Emergency Maintenance is likewise Excluded Downtime under the SLA.

Where our monitoring or our operations staff identify an incident affecting message submission, we notify the account contacts of the customers we assess to be affected. A first notice states what is known at the time: the component affected, when the condition began in UTC, the observed impact and any workaround. We do not delay it to state a cause.

Incidents are classified using the severity levels in the support section of the SLA (P1 critical, P2 degraded, P3 partial, P4 question or request). The target initial response window for each severity is stated there and is deliberately not repeated here, so the two documents cannot drift apart. SMSBite assigns the final severity, acting reasonably.

Updates continue at reasonable intervals until resolution, followed by a closing notice. For a P1 incident, a written summary of the impact, the period affected and the remedial steps taken is provided on request. Notices are informational and do not themselves establish Downtime, which is measured and claimed under the SLA.

Report a suspected incident by email to sales@smsbite.com. Please include all of the following:

• The time range affected, stated in UTC.
• The destination country or countries.
• The affected sender ID.
• Your own request identifiers.
• A representative sample of affected message identifiers.
• The behaviour observed versus the behaviour expected, including any HTTP status or error codes returned.
• Whether submission or deliveryis affected — whether the API failed to accept your requests, or accepted them while the messages did not reach handsets.

This matters because submission and delivery problems have different causes and different owners. A submission failure sits on the SMSBite control plane and is the only category measured by the availability target. A delivery failure usually originates with an operator, an aggregator partner or a destination-country rule, and is investigated by route, destination and sender ID rather than by endpoint. Without the time range, destination and identifiers we cannot isolate your traffic in the logs.

Most reports of “messages not arriving” are not platform downtime. Once a Submission is accepted the message passes to networks SMSBite does not own or control. None of the following is downtime, and none is covered by the availability target:

• Operator-side spam, content or volume filtering.
• Sender-ID blocking or rewriting.
• Content rejection under operator or registry rules.
• Destination-country regulatory blocks, category bans and route suspensions.
• Number portability lag or bad portability data.
• Roaming conditions and recipient-network routing.
• Handsets switched off, out of coverage, barred or otherwise unreachable, and invalid MSISDNs.

We investigate all of them regardless. Where the cause is upstream we open a case with the operator or aggregator partner, pursue it through our supplier escalation path and report back what we learn; where a route is structurally impaired we move the traffic. Resolution timing on the operator side is outside our control, and a national regulatory block is a decision only the regulator can reverse. The Service Level Agreement sets out precisely what the availability target measures.

Security matters do not go through the support address. Suspected vulnerabilities, suspected compromise of an account or of API credentials, and suspected exposure of data go to security@smsbite.com.

Our technical measures and vulnerability reporting process are on the Security page. Our notification duties following a personal data breach, and the timelines applying to them, are set out in the Privacy Policy. They are not restated here so that a single statement of those duties governs.

Abuse of the platform — unsolicited traffic, phishing or fraudulent content sent through SMSBite — goes to abuse@smsbite.com.

Material changes to the Service or its policies — deprecation of an API endpoint, withdrawal of a feature, or any change that adversely affects your rights or materially modifies your obligations — are notified to account contacts by email and posted on the relevant page at least thirty (30) days before they take effect, in line with the Terms of Service and the SLA. Non-material changes — clarifications, formatting and typographical corrections — take effect on publication.

A policy change is announced on that policy’s page, which carries its own effective date and version in the header; interface changes are also described in the developer documentation supplied with your account. Route availability, operator profiles and sender-ID options can change at short notice for regulatory or risk reasons and are not subject to the thirty-day period.

Changes do not apply retroactively. A calendar month already in progress when a change takes effect is measured, and any claim for it assessed, under the version in force on the first day of that month.

This page is issued by SMS Bite Limited, trading as SMSBite, incorporated in Hong Kong under Company Registration N° 78685084, registered office as set out above.

Related policies: Service Level Agreement, Terms of Service, Security and Privacy Policy.