Service levels

What is measured, what is committed, and what sets the ceiling. Availability percentages, support hours and response targets are agreed in the partner agreement rather than published here, and the reason is in the architecture section below. Everything on this page is running and verifiable today.

What the service is

• The application. The Joulely web application and API, over HTTPS.
• The partner surface. Partner-branded views, embedded from the partner's own app or website.
• The partner API. Programmatic submission of customer data and retrieval of insight.
• The bill-engine API. The bill-reading API, documented on the developers page and governed by the API terms.
• The mobile app. Distributed through Google Play. Availability of the store itself is outside our control.

Excluded from any availability measurement, because they are outside our control and no commitment we made about them would be worth anything: the smart-meter data chain, which is the DCC, the meter, the household's communications hub and the meter-data provider; the partner's own systems, authentication, network and feeds; Google Play, the payment processor and the email provider; maintenance notified under the maintenance section; and anything caused by misuse or by force majeure. A meter that stops reporting is not a Joulely outage and we cannot fix it.

The architecture, because it sets the ceiling

• One virtual server in Nuremberg, Germany. The application, the database, the mail service and the administrative console are all on it. There is no failover, no standby and no load balancing. If that server fails, the service is down until it is restored.
• Why it is built that way. A redundant architecture costs more than the service currently earns. A partner is better served by knowing the shape of the risk than by an availability figure the architecture cannot support.
• What that means for you. Planned host maintenance and reboots cause brief outages. An unplanned host failure means a rebuild and restore, not a failover. The service is not appropriate today for a use case where an outage here would stop a household doing something time-critical: it is an insight and analysis layer, not a billing system or a meter system of record.
• If you need a redundant deployment, raise it before signature. Removing the single point of failure is a commercial conversation, not a promise this page can make.

Availability

• A watchdog every 30 minutes. Requests the health endpoint and the key public pages over the public internet, scans the application error log, and checks background jobs and data freshness.
• A deep health monitor every 3 hours. Renders signed-in pages for a real meter-connected user and for a user without a meter, which catches failures a status-code check would miss.
• A nightly audit at 03:20 UTC. Ten checks including endpoint reachability, rendering and stale data. Results kept for 90 runs.
• An operational digest daily at 07:13 UTC. Availability, errors and usage over the preceding day.
• The limit of that measurement. A 30-minute polling interval means an outage shorter than 30 minutes may not be observed at all, and an outage is timed to the nearest poll, so any figure derived from it is accurate to within about half an hour per incident. A partner needing finer measurement should say so: external per-minute monitoring is cheap to add and is the right thing to have before committing to a percentage.
• The committed availability figure is agreed in the partner agreement. None is published here. On a single host with unattended patching reboots, a figure taken from an industry template would be a number invented to fill a box, and the first month it was missed the partner would be entitled to say so. Service credits, or a termination right in place of them, are settled in the same agreement.

Backup, recovery and data loss

• Nightly at 03:30 UTC, encrypted, on a systemd timer. Primary copy in Nuremberg, Germany. Second copy in Falkenstein, Germany, in a different data centre. Retention is 7 daily, 4 weekly and 6 monthly.
• Recovery point objective: 24 hours. Because backups are nightly, the worst case is the loss of one day of data written since the last snapshot. That is a property of the mechanism rather than an aspiration.
• No recovery time objective is committed. A restore of the database dump was tested successfully in July 2026. A complete recovery from total host loss, meaning provision, configure, restore and verify, has never been rehearsed end to end, so any figure stated now would be a guess.
• One data-loss disclosure. The encryption keys are deliberately excluded from the backups. If a key is lost, the data encrypted under it cannot be recovered from a backup. Keys are held off-server in a password manager. The security statement sets out why that trade was made.

Maintenance

• Automatic security patching is on and runs daily. Patches that need a restart cause a brief interruption. An unpatched host is a worse risk to a partner's data than a short restart, and it is stated here so it is not mistaken for an incident.
• Routine deployment: no notice. Deployments are built to avoid any interruption. Where one needs a restart, the interruption is seconds.
• Planned maintenance causing a material interruption: at least 5 working days' written notice to the partner's named contact. Maintenance notified under this section is excluded from availability measurement. The standard window is set in the partner agreement.
• Emergency maintenance to preserve security or integrity. As much notice as is reasonably possible, and always notice afterwards explaining what was done and why.

Support

• The partner's own team supports the partner's own customers. This is structural. We never learn a partner customer's identity, hold no contact details for them and do not authenticate them, so we are not able to support them directly and should not try. It is also what keeps the price at 5p or 10p rather than several times that.
• We support the partner. Named technical contacts, integration questions, incidents, data-protection requests and escalations from the partner's own agents.
• If a partner customer contacts us directly, we will not respond substantively. We refer them to the partner and notify the partner within 2 working days. That is contractual.
• Channels. Partner support and incidents: business@joulely.co.uk. Security vulnerability reports: security@joulely.co.uk. Article 28 requests go to the business address marked for the data-protection contact. Named individuals, an out-of-hours route for incidents, and support hours are set in the Order Form of the partner agreement.

Severity levels

The definitions are fixed. The target response and update frequency for each are agreed in the partner agreement. “Response” means a human acknowledgement from someone who can act, together with an initial assessment. An autoresponder is not a response and the agreement says so.

• P1, critical. The service is unavailable to all partner customers, or partner data is at risk.
• P2, major. A core function is unavailable or materially degraded for a significant proportion of partner customers, with no workaround.
• P3, minor. A non-core function is impaired, or a workaround exists.
• P4, request. A question, a change request, or a documentation issue.

Deadlines that are already firm

These are not placeholders. They are contractual today under the data processing agreement and the master services agreement.

• Notification of a personal data breach affecting partner data: 24 hours from becoming aware.
• Updates while a breach incident is open: at least every 48 hours.
• Written post-incident report including root cause: 20 working days from closure.
• Acknowledgement of a data-subject request forwarded by the partner: 2 working days.
• Completion of a data-subject request: 10 working days. Access, rectification, restriction or erasure. Set so the partner can meet its own one-month statutory deadline with room to spare.
• Notification if a partner customer contacts us directly: 2 working days.
• Deletion of an individual record on instruction: 5 working days.
• Provision of information for a DPIA on request: 20 working days.
• Full data export on request: 20 working days.
• Deletion or return of all partner data at the end of processing: 30 days, with written certification.
• Notice before adding or replacing a sub-processor: 30 days, with a 14-day objection right.
• Notice before any change of processing location: 30 days, with an objection right.
• Notice of planned maintenance causing a material interruption: 5 working days.
• Notice of a breaking API change: reasonable notice, never applied retroactively.

Version 2026-08-13. This page attaches to the master services agreement as a schedule. Questions to business@joulely.co.uk.

Trust pack · Security · Sub-processors · Data processing agreement