When a digital twin platform becomes part of a production line, a supply chain integration, or a Digital Product Passport, it stops being “just another SaaS”. If it is down, an engineer somewhere cannot pull the parameters for a new device, a partner’s integration stops receiving submodel updates, and a customer scanning a product’s QR code gets an error page instead of its passport. Reliability is not a nice-to-have for twinsphere, it is a key part of the product.
Operating software this way is not something we started with twinsphere. At conplement AG, we have been building and running production platforms with a site reliability engineering (SRE) mindset for many years, for our own products and for our customers. twinsphere is built on that experience. This post is a short look at the practices behind it. None of them are our invention: most are well-established and publicly documented, above all in Google’s Site Reliability Engineering books.
The practices
Service level objectives (SLOs), not gut feeling. We define what “working”
means for each service in terms users care about, not CPU graphs. An API that answers
with 200 OK is not enough. Synthetic probes run real user journeys against
production multiple times per minute. A typical probe signs in, reads a shell and
checks that real twin data comes back. SLOs on these semantic checks give us a
shared, measurable target and tell us when reliability work needs to take
priority over feature work (see
Service Level Objectives
and the idea of an
error budget).
Observability built in from day one. Every service is designed with observability in mind. When something degrades, we want to answer “which tenant, which endpoint, which dependency” in minutes, not hours.
Alerting on symptoms. We alert on what users feel (errors, latency, failed requests), not on every internal signal that might be fine. Fewer, better alerts keep on-call sustainable and keep the signal meaningful. This follows the “symptoms, not causes” principle and the four golden signals from Monitoring Distributed Systems (see also Alerting on SLOs).
On-call with clear ownership. The team that builds a service also runs it, in the spirit of “you build it, you run it”. There is always someone responsible, with runbooks and the access they need to act (see Being On-Call).
Blameless post-incident reviews. When something goes wrong, we look at the system, not the person. Every incident ends with concrete follow-ups that make the same failure less likely or less painful next time, as described in Postmortem Culture: Learning from Failure.
Boring, repeatable deployments. Everything runs automated, is described as code, and goes through pipelines with preview environments. Rollouts are routine and rollbacks are fast, which is exactly how deployments should feel.
Transparency: status.twinsphere.io
Good operations should be visible to the people who depend on them. That is why the live status of twinsphere is public at status.twinsphere.io, giving customers the same picture we have internally without having to open a ticket:
- Current status of twinsphere Cloud (
cloud.twinsphere.io), twinsphere Management (manage.twinsphere.io) and twinstudio (studio.twinsphere.io). - 90-day uptime history per service, day by day, with operational, degraded, maintenance and outage states.
- Scheduled maintenance, announced at least 48 hours before any planned work.
- Incident history, so that past disruptions and their resolution stay visible and do not quietly disappear.
Why this matters for you
If you build on twinsphere, you are building on top of our operations, whether you think about it or not. Our goal is that you never have to: the platform stays up, and when it does not, you learn about it from us first, with an honest picture of what is happening.
If you have questions about our reliability practices or need specific service level agreements (SLAs) for your use case, get in touch.