Service levels and support
Last updated: 19 September 2026
Draft, subject to contract. These terms are still in review and the wording may change. They show what we intend to offer, and they are not a binding offer: the plan, service levels, hosting and recovery arrangements that apply to you are the ones in your signed agreement.
These are the service levels we intend to offer. The plan, availability, support cover and recovery commitments that apply to you are the ones confirmed in your signed agreement.
1. Availability target
| Plan | Monthly availability target | Service credits |
|---|---|---|
| Starter | 99.5% | Not offered |
| Professional | 99.5% | Not offered |
| Enterprise | 99.9% | As stated in the signed agreement |
Availability is measured monthly as the percentage of time the platform API responds successfully to health checks, excluding scheduled maintenance and events outside our reasonable control.
2. Data ingestion continuity
Where a supported site gateway is deployed, readings are buffered locally while the connection to the platform is down and are sent when it returns, provided the gateway stays powered. Buffer duration depends on the gateway hardware and your reading frequency, so the duration commissioned for your site is recorded in your order form and tested at commissioning. A reading a sensor never took cannot be recovered.
3. Scheduled maintenance
- Notified at least 5 working days in advance
- Normally performed between 01:00 and 05:00 UK time
- Excluded from availability calculations
- Emergency maintenance for security may be performed with shorter notice; we will tell you as soon as we can
4. Support hours
| Plan | Channel | Hours |
|---|---|---|
| Starter | 09:00 to 17:00 UK time, Monday to Friday | |
| Professional | Email; phone if quoted | 08:00 to 18:00 UK time, Monday to Friday |
| Enterprise | Named channels in the agreement | Extended cover as stated in the signed agreement |
Excludes England and Wales bank holidays.
5. Priority definitions and response targets
| Priority | Definition | Starter / Professional | Enterprise |
|---|---|---|---|
| P1: Critical | Platform unavailable, or sensor ingestion stopped across a site | 4 working hours | 1 hour |
| P2: High | A module is unusable, or alerting is not firing | 1 working day | 4 hours |
| P3: Medium | A feature is degraded but there is a workaround | 3 working days | 1 working day |
| P4: Low | Cosmetic issue, question or feature request | 5 working days | 3 working days |
Enterprise response targets stated in clock hours apply within the cover hours set in your agreement. These are targets for first substantive response, not resolution. We will tell you what we know, what we are doing and when you will hear from us next.
6. What support covers
Included: platform faults, configuration questions, user administration, guidance on using features, help interpreting data the platform produces, and assistance with exports.
Not included: maintenance of your sensors, controllers or network; agronomic advice; bespoke customisation; and training beyond the onboarding programme. We can quote separately for these.
7. Backups and recovery
Backups are automated, encrypted, and written off the database host. Recovery objectives are stated by data tier, because a lost session cache and a lost hour of sensor history do not carry the same cost.
| Data | Recovery time objective | Recovery point objective |
|---|---|---|
| Operational record, sensor history and identity data | 4 hours | 1 hour |
| Session state and model artefacts | 8 hours | 24 hours |
| Broker and dashboard configuration, which is rebuildable | 24 hours | 7 days |
Recovery time is measured from the declaration of an incident to production traffic being served again on restored data. These are the objectives we commit to for your environment, not a description of drills already performed: BeeGrow AI has not yet run a production restore for a customer, because it does not yet have one.
What we commit to instead is the regime that makes them real. Before your environment carries production data we will perform a timed full-system restore into a clean environment and give you the result in writing, including the measured recovery time against each tier above. From then on we repeat that drill at least quarterly, and we will confirm the date and result of the most recent one on request. If a drill misses an objective we will tell you, rather than waiting to be asked.
8. Incident communication
For P1 incidents we post updates at least hourly until service is restored, and publish a written incident summary within 5 working days covering what happened, the impact, and what we are changing.
9. Contact
Support: hello@beegrow.ai. Enterprise customers should use their named contact channel for P1 incidents.