Service Level Agreement

This agreement sits under the Terms of Service and forms part of it. It applies to every paid plan. Free trials, beta features and accounts in arrears are outside it.

1. What this covers

The commitments below apply to the Growcord platform: the dashboard, the public API, the webhook receiver, the chatbot engine and the scheduled sending pipeline. In short, the parts we build and operate.

They do not apply to the WhatsApp Business Platform itself. Meta operates that, decides whether a message is delivered, sets your quality rating and messaging limits, and reviews your templates. We are not able to offer a service level on a system we do not run, and any provider who tells you otherwise is selling you a promise they cannot keep.

2. Definitions

Available

The platform accepts authenticated requests and returns a correct response. A single failed request is not unavailability; a sustained failure rate is.

Downtime

Any period of five consecutive minutes or more in which more than 5% of valid requests to the platform fail with a server error, or the dashboard cannot be loaded by a signed in user.

Monthly uptime percentage

Total minutes in the calendar month, minus downtime minutes and minus excluded minutes, divided by total minutes in the month, minus excluded minutes.

Excluded minutes

Any period falling under clause 5 or clause 6.

Service credit

A percentage of that month's subscription fee, applied against your next invoice.

Business hours

Monday to Saturday, 10:00 to 19:00 IST. Public holidays in Delhi are excluded.

3. Uptime commitment

We target a monthly uptime percentage of 99.9% across every plan, and we commit contractually to the figures below. The commitment is lower than the target on purpose: a commitment should be a floor you can hold us to, not an aspiration.

4. How uptime is measured

Measurement is taken from our own monitoring, which checks the API and the dashboard from outside our network at one minute intervals, and from the server side error rate recorded in the application logs. We use a calendar month, in Indian Standard Time.

If your own monitoring disagrees with ours, send us the data. Where the two conflict and we cannot reconcile them, we will resolve the difference in your favour. It is a better outcome than arguing about whose probe was right.

5. What does not count as downtime

These periods are excluded from the calculation. Most of them are things that feel like an outage from the dashboard but originate somewhere we do not control.

• Meta and the WhatsApp Business Platform. Any outage, degradation, rate limit, queue delay or policy action at Meta's end.
• Restrictions on your number. A quality rating drop, a lowered messaging limit, a paused template, a business verification hold, or a ban.
• An empty wallet. Sending stops when the balance runs out. That is the system working as designed.
• Plan limits. Hitting your conversation, bulk message, contact or seat limit.
• Scheduled maintenance announced under clause 6.
• Emergency maintenance needed to close a security hole, capped at 2 hours per month.
• Other third parties. Razorpay, your store platform, your DNS, your email provider, or the AI model provider you selected.
• Your own systems. A webhook endpoint that is down, an integration you misconfigured, a revoked API key, or your local network.
• Misuse. Load testing without permission, deliberately abusive request volumes, or a breach of the acceptable use clause.
• Suspension for non payment or for breach of the Terms of Service.
• Force majeure as described in the Terms of Service, including internet shutdowns and government orders.
• Beta features clearly labelled as such in the product.

6. Maintenance windows

Most changes ship without downtime. When a change does need a window, we take it between 01:00 and 04:00 IST on a Sunday, which is the quietest period in the traffic we see.

• Planned maintenance is announced at least 48 hours ahead, by email and in the dashboard.
• Planned maintenance is capped at 4 hours per calendar month.
• Emergency maintenance, for a security fix that cannot wait, is announced as soon as we can and is capped at 2 hours per month.
• Inbound messages are queued during maintenance wherever technically possible, so conversations are not lost.

7. Incident severity

Severity is set by impact, not by how urgently it was reported. We will tell you what we have graded something as, and if you think it is wrong, say so and we will look again.

P1 Critical

The platform is down or unusable for all customers, or no messages can be sent or received at all. Data loss or an active security incident also grades P1.

P2 High

A core function is broken for you: campaigns will not send, the inbox will not load, webhooks are not arriving, billing has charged incorrectly. There is no reasonable workaround.

P3 Medium

Something is wrong but there is a way around it. A report is miscounting, a screen renders badly, an export is slow.

P4 Low

Questions, configuration help, feature requests and cosmetic issues.

8. Support response and resolution targets

First response is the time until a person who can actually help replies, not an automated acknowledgement. Targets are measured during business hours, except for P1 on plans with priority support, which is worked around the clock until it is resolved.

We commit to response times rather than fix times, because an honest fix time depends on what the bug turns out to be. What we do commit to is that a P1 is worked continuously until it is resolved or reduced to a lower severity, and that you get a written update at least every 2 hours while it is open. A P2 gets a daily update until it is closed.

Managed, Managed Pro and Managed Scale include a named account manager rather than a queue. Enterprise includes priority routing on the same channels. What each plan includes is set out on the Support page.

9. Service credits

If we miss the uptime commitment for your plan in a calendar month, you are entitled to a credit against your next invoice.

A missed first response target on a P1 or P2 adds a further 5% credit for that month, capped at 10% however many are missed.

• Credits are calculated on the subscription fee for the affected month only. On a yearly plan that is the annual fee divided by twelve.
• Message costs are excluded from the calculation, because they are Meta's revenue and not ours.
• Total credits in any month are capped at 50% of that month's subscription fee.
• Credits are applied to a future invoice. They are not paid in cash and cannot be transferred to another account.
• Service credits are your sole and exclusive remedy for a failure to meet the uptime commitment.
• No credit is due on an account that is in arrears at the time of the incident.

10. How to claim a credit

Email [email protected] with "SLA credit" in the subject, within 30 days of the end of the month in question. Include the dates and times of the downtime you observed, and anything that evidences it: request logs, error responses, screenshots or your own monitoring output.

We respond within 10 working days with the uptime figure we recorded and the credit we agree is due. Where our own monitoring already shows we missed the commitment, we will apply the credit without waiting to be asked, and tell you we have done so.

11. Backups and data durability

• The database is backed up daily, and backups are retained for 30 days.
• Restores are tested periodically. A backup nobody has restored is a guess, not a backup.
• Our recovery point objective is 24 hours and our recovery time objective is 8 hours for a full platform restore.
• Media uploaded to the gallery is stored on redundant object storage with its own durability guarantees.
• You can export your contacts, conversations and message history from the dashboard at any time. Keeping your own copy of anything you cannot afford to lose is sensible, and we encourage it.

12. Security and incident response

• Critical security patches are applied within 7 days of a fix being available.
• A confirmed personal data breach is reported to the Data Protection Board of India without delay, with the full account inside 72 hours, and affected people are notified. The detail is in the Privacy Policy.
• Where a security incident affects your account specifically, we tell you within 24 hours of confirming it, whether or not it amounts to a reportable breach.
• A post incident summary is published for any P1 lasting more than an hour, setting out what happened, why, and what we changed so it does not happen again.

13. What we need from you

These commitments assume a few things from your side. They are not onerous.

• Report problems through the ticket system or the support email, so there is a record.
• Give us enough to reproduce the problem: what you did, what happened, the time, and the message or request ID where there is one.
• Keep a reachable contact on the account and answer follow up questions.
• Keep your webhook endpoint responding, and your API keys and integrations current.
• Keep the account paid up.
• Stay inside the acceptable use rules in the Terms of Service.

14. Changes to this agreement

We may update this agreement. Where a change reduces a commitment, it takes effect 30 days after we notify you by email and in the dashboard, and it does not apply retrospectively to a month already underway. Improvements take effect immediately.