Good to know

Turbit is a Software as a Service Product that is based on a per module and per MW monitored pricing. Ask our experts to get a tailored offer.

Turbit's AI runs on your SCADA data, learns each turbine's individual normal behaviour, and flags anomalies — power curve drift, bearing temperature drift, generator faults, gearbox issues — months before they become failures. Operators reduce unplanned downtime by ~60% in the first year, recover lost production, and turn surprise repairs into planned maintenance. Customers across 3,500+ turbines and 40+ portfolios use it today.

Most operators see payback within 12–18 months. Two compounding sources: (1) avoided component failures and unplanned downtime — a single prevented main-bearing exchange can pay for the year; (2) better insurance terms when Turbit Blue is included, since the insurer counts the AI monitoring as risk reduction. Use our ROI calculators (password-gated; ask your Turbit contact) to model your fleet specifically.

Yes — pricing scales per turbine. Smaller operators typically start with one or two parks, see results within a quarter, and expand. There's no minimum portfolio size and no setup fee beyond the data check.

Yes — through a backtest. We run Turbit's AI on 3+ years of your historical SCADA data (5+ ideal) for as many turbines as you bring, on a one-time fee with no commitment. You see exactly when Turbit would have flagged the failures you actually had, what the alarm would have said, and which actions would have been justified. It's the cleanest way to validate the system on your own assets before signing a monitoring contract.

We train an individual neural network per turbine on your historical data, replay the time window, and show every detection event the system would have produced — severity, root-cause prediction, the date it would have triggered. We then walk through the events with your team: which were already known, which were missed, and what an O&M team could have done differently. The output is a decision document, not a marketing demo.

3 years of SCADA history per turbine is the minimum; 5+ years is ideal. We accept exports from all major OEMs (Vestas, Siemens Gamesa, Nordex, Enercon, GE) and from AMS platforms like Bazefield and Greenbyte. If your data has gaps, we'll tell you up front whether the result will still be conclusive.

Two weeks from data hand-over: ~1 week of data prep + per-turbine training, then a walkthrough call with our team. Send fleet data and the incidents you want to see flagged; we come back with a fixed price and a target evaluation date.

Turbit trains an individual neural network per turbine on its historical SCADA data — Wind speed, temperatures, power, direction. The model learns each machine's normal behaviour, then flags deviations in real time. A second AI layer classifies each anomaly by likely root cause and predicts its relevance. Customer feedback retrains the models, so detection improves with every confirmed alarm. Read the deep dive on our AI Infrastructure page.

More than 35 distinct failure modes — main bearing damage, generator winding issues, gearbox lubrication problems, frequency converter faults, blade-pitch misalignment, yaw misalignment, soiling-driven power curve drift, control-system curtailment, clogged oil filters, broken cooling fans, and more. Coverage depends on your data quality; we run a free data check before any engagement to set expectations.

About 5 alerts per 100 turbines per week on a typical fleet, with a false-positive rate under 10%. A team can review 300 turbines in roughly 30 minutes per week. Detection latency is under 4 hours from when the anomaly occurs.

Three things. First, individual neural networks per turbine — not fixed thresholds or fleet-average models — so we catch deviations that average-based systems miss. Second, AI-driven root-cause prediction and relevance scoring on every alarm, not just a flag. Third, the only platform on the market with integrated insurance via Turbit Blue (HDI Global) — your monitoring and risk-coverage stack on the same data layer.

Training Turbit's neural networks takes under a day per turbine. Once data flow and signal-mapping checks are complete, the entire fleet is online within a week.

Ideally 24 months of SCADA per turbine. With less, transfer learning lets us start from one month — slightly lower coverage initially, refined as more data arrives. The data-requirements page lists the exact signals each module needs.

No — Turbit is software-only and works on the SCADA data your turbines already produce. We can optionally ingest CMS / blade-vibration data for richer coverage, but no extra hardware is required to start.

No — the EventCard view is built for O&M teams, not data scientists. Every alarm is presented with a plain-English description, the relevant plot, the AI's root-cause prediction, and recommended next steps. We also run a kickoff workshop and Customer Success calls so your team has direct access to a Turbit engineer.

Mapping is critical — wrong signals mean wrong models. Turbit uses statistical analytics and language models to score each signal's likely identity, plus manual checks where confidence is low. Mappings often change over time at the asset; Turbit detects the resulting anomalies automatically and flags frozen or misnamed sensors.

Using AI and machine-learning models to watch each turbine's actual operating data in real time, learn its normal patterns, and predict component failures before they happen. The result is fewer surprise breakdowns, better-timed maintenance, and longer asset life.

Standard SCADA — power, wind speed, temperatures, pressures, status codes — is the baseline. Vibration / CMS data, blade-sensor data, weather data, and maintenance history all sharpen the picture. Turbit works with whatever you have, with coverage scaled to data quality.

Curtailment is a known challenge — a model that hasn't seen reduced operation can confuse it with a fault. Turbit's per-turbine models learn from your turbines' actual curtailment patterns and treat verified curtailment events as valid (not anomalies). For long offline periods, models pause and resume training with the new operating window.

FSAs cap liability — historically at numbers that haven't kept pace with turbine sizes. A 7 MW turbine's 12-month outage now exceeds typical liability caps several times over. Turbit's monitoring catches issues months before they hit the FSA's intervention threshold, lets your team verify the OEM's response, and (with Turbit Blue) closes the residual liability gap. The math typically holds even alongside an existing FSA.

Both. The same model that flags developing failures also surfaces underperformance — power-curve drift, yaw misalignment, pitch errors, soiling — that costs you production. We don't issue control commands ourselves; we hand the operator a quantified opportunity to act on with the OEM or service provider.

This is the core advantage of per-turbine modelling. Each machine has its own normal-behaviour fingerprint — its history, site, components, control settings. Turbit's neural networks learn that fingerprint, so deviations stand out cleanly against an honest baseline rather than against an industry average that doesn't fit.

Two mechanisms. First, the relevance-prediction layer pre-filters — alarms below the priority threshold don't reach your inbox. Second, your feedback retrains the models: every confirmed-or-rejected alarm tunes sensitivity for similar situations. False-positive rate stays under 10% across our fleet.

Yes — most turbines built after 2005 have enough SCADA signals for component-level monitoring. Newer turbines with richer sensor packages produce sharper models, but temperature, pressure, and power signals alone reveal most developing problems.

Component-dependent. Main bearings: trend visible 1+ year before action is needed (see the VSB customer story). Generator winding issues: 3–6 months. Gearbox lubrication problems: weeks to months. Blade damage with CMS data: weeks. The longer the lead time, the cheaper the fix.

Different jobs. Weather forecasting maximises production from healthy turbines. Predictive maintenance keeps the turbines healthy. Both matter — high wind isn't useful if a gearbox fails in the middle of the season.

Three steps over ~2 weeks: (1) data check + signal mapping (we work with your IT or AMS provider; minimal effort from your team), (2) per-turbine model training and dry-run, (3) go-live workshop with your O&M team. After onboarding the typical commitment is 30 minutes per week per 100 turbines — review the alerts, mark relevance, schedule actions. Customer Success is on a weekly or bi-weekly call until your team is independent.

Live alarms in the Turbit web app, with EventCards (plot + plain-English narrative + root-cause prediction + recommended action). Email notifications for high-priority events. Monthly portfolio reports for asset managers. Per-turbine deep-dive reports on demand. API access for integration with your reporting stack. All outputs include the underlying data so your engineering team can verify findings.

Detection latency is under 4 hours from the data point that triggers it. Notifications go out via email by default; configurable per user, per severity, and per turbine. Alerts surface in the Turbit web portal in real time and are also exposed via API for integration with existing ticketing systems.

Yes — Vestas, Siemens Gamesa, Nordex, Enercon, GE, Senvion, Goldwind and others. Turbit only needs SCADA data, which is standardized across the industry. We've deployed across mixed-OEM portfolios; the same Turbit account handles them in one view.

No — Turbit is read-only on SCADA data and never issues control commands. There's no warranty implication. In practice, OEMs welcome it: clear evidence of a developing issue lets them schedule maintenance instead of getting paged for emergency repair. We've worked alongside Vestas, Siemens Gamesa, Nordex, Enercon, GE and SAB without a single warranty concern.

Each turbine gets its own neural network trained on its own data — OEM-agnostic. Turbit's portfolio view shows mixed fleets in a single dashboard. The signal-mapping layer handles OEM-specific tag naming so your team doesn't see the difference.

We pull data from any major AMS — Bazefield, Greenbyte, Bax Energy, WIS, Rotorsoft, WEO, and others — via standard interfaces (OPC, IEC 61400-25, REST, file-based exports). For direct turbine connections we support OPC DA/UA and IEC 61850/60870. Custom protocols are usually a few days of work.

An insurance integration product that uses Turbit's AI monitoring as the risk-reduction layer. It closes the gap between your full-service-agreement liability cap and the actual cost of a 12-month component outage on modern turbines — a gap that's grown from ~30k EUR per turbine in 1995 to over 1.3M EUR for 7 MW assets. Available with Turbit Monitoring; up to 30% lower total cost vs. the typical alternative.

FSAs cap liability — usually around 100–115% of the annual service fee. Modern turbines' outage costs blow past that cap on a single major component failure. Turbit Blue covers the residual exposure: the difference between what the FSA pays out and what a multi-month component outage actually costs you. Two product variants — AI Add-On (gap insurance on top of an FSA) and AI Full Coverage (alternative FSA + insurance bundle).

HDI Global SE underwrites turbines that have Turbit Blue. Turbit isn't a broker and doesn't sell insurance ourselves; we provide the AI monitoring layer that makes the insurance economically viable. HDI is a globally rated insurer with extensive renewable-energy underwriting experience.

Monitoring without insurance — yes, that's our most common deployment. Insurance without monitoring — no; the AI layer is what HDI counts as risk reduction in the underwriting, and it's how the math works out. Start with monitoring; add Turbit Blue when your FSA renewal is on the horizon.

Often, yes — even without Turbit Blue. Insurers increasingly offer better terms to operators with proven predictive monitoring; the demonstrated risk reduction lowers the risk and thus can increase coverage or lower the premium. Some operators find that the insurance savings alone offset their monitoring system cost and beyond that can save up to 30% of OPEX.

All data lives in EU-based ISO 27001-certified data centers (no hyperscaler lock-in; bare-metal hosting). Encrypted in transit (TLS) and at rest. Customer data is logically isolated per tenant and never combined for cross-customer model training without explicit opt-in. Full security overview is on our /compliance page.

Turbit is in the active ISO/IEC 27001 certification process, expected to complete in Q1 2026. Internal policies, controls, and audits are already in place to meet the standard. Most of our customers are themselves classified as critical infrastructure — we work to their requirements every day.

GDPR: we process operational and SCADA data, not personal data; customer business contacts are stored only as needed for support. Your data residency is EU-only. EU AI Act: Turbit Monitoring is classified minimal/limited risk (no autonomous safety-critical control), with transparency, explainability, and human oversight built into every detection. DPAs and security overviews are available on request.

Turbit is owned by its founders Michael Tegtmeier (CEO) and Christian Fontius (CRO), with backing from Vinci Venture Capital and known Business Angels. Independent — no operator, OEM or insurer holds a controlling stake.

The signature is a slow, sustained temperature rise relative to what the bearing should be running at for the given wind speed, power and ambient conditions — not an absolute threshold. That distinction matters: a bearing running warm on a hot afternoon at rated power is normal, and the same reading on a cool morning at part load is not. Turbit learns each turbine's own relationship between load, weather and bearing temperature, then flags sustained deviation from it. Because the drift develops over weeks or months, this is one of the failure modes where early detection changes the outcome most: a planned bearing exchange and an unplanned one are very different numbers. Worked example with real data: /wind-turbine-failures/main-bearing-temperature-rise

Some gearbox failure modes, yes — lubrication problems, oil-filter clogging, cooling-circuit degradation and the temperature signatures that follow all show up in SCADA data, because they change the thermal behaviour of the gearbox before they change anything a controller alarms on. Gear-tooth and gear-mesh defects are a different matter: those are vibration phenomena, and a vibration CMS with accelerometers on the drivetrain is the better instrument for confirming and characterising them. The honest position is that SCADA analytics widens coverage to every turbine with no hardware, and vibration adds depth on the drivetrain specifically. If gearbox risk is your main concern and you already have vibration hardware, the two are complementary rather than competing.

Winding faults and generator bearing degradation both leave thermal and electrical traces in SCADA well before a fault is declared — typically an asymmetry or drift that only becomes visible once you know what that specific generator normally does under comparable load and ambient conditions. Turbit models each generator individually rather than comparing it to a fleet average, which is what makes a few degrees of unexplained deviation meaningful instead of noise. Two worked examples with real data: /wind-turbine-failures/generator-winding-fault and /wind-turbine-failures/generator-bearing-temperature-rise

Partly, and it is worth being precise about the boundary. Blade-pitch misalignment, soiling and icing all change the power curve, so SCADA analytics detects them — and they are common, costly and easy to miss because the turbine keeps running. Structural blade damage — cracks, delamination, lightning strike damage — does not reliably show in SCADA at all, because a damaged blade can produce a normal power curve right up until it does not. That needs the blade monitoring product, which uses vibration sensors on the blades themselves. If your concern is structural blade integrity, SCADA analytics is not the right instrument and we would say so.

The method does not depend on where the turbine stands: it needs SCADA data, and offshore turbines produce it. The economics change in our favour rather than against it — offshore access is expensive and weather-dependent, so knowing about a developing fault weeks ahead is worth considerably more than it is onshore, where a technician can drive out on short notice. What is genuinely different offshore is the surrounding context: the transport and vessel planning around any intervention, and the higher bar on evidence before a campaign is scheduled. If you are evaluating for an offshore portfolio, ask us directly rather than assuming from an onshore reference — the analysis transfers, the operational picture around it deserves a specific conversation.

They answer different questions, and plenty of portfolios run both. A vibration CMS puts accelerometers on the drivetrain and sees bearing and gear-mesh defects with high specificity — it is the better instrument for confirming and characterising a known drivetrain problem. SCADA analytics uses data every turbine already produces, so it covers the whole machine and the whole fleet with no hardware: power anomalies, temperature drift, control and alignment faults, and components a vibration sensor is not attached to. The practical difference is coverage versus depth. If you have no monitoring at all, SCADA analytics covers more turbines for less money and needs no site visit. If you already have vibration hardware on the drivetrain, SCADA analytics is what covers everything the sensors do not.

Scope and incentive. An OEM system monitors its own fleet against its own thresholds, which is genuinely useful and also means the party assessing a developing fault is the party who may be liable for fixing it. An independent layer reads the same SCADA data across every manufacturer in your portfolio, so mixed-OEM fleets appear in one view with one set of conventions, and the assessment you take to a service negotiation is not produced by your counterparty. It is additive rather than a replacement: Turbit is read-only and issues no control commands, so it sits alongside OEM monitoring rather than displacing it.

A portfolio platform is built to aggregate and report: it collects SCADA, computes availability and production, and shows you what happened. Condition monitoring is built to predict: it learns each turbine's normal behaviour and flags deviation before it becomes a fault. Most platforms surface threshold alarms the turbine controller already raised, which is a different thing from detecting drift the controller does not consider abnormal yet. In practice the two compose well — the platform stays your reporting system of record, and monitoring findings arrive via API or email into the workflow you already use.

Three routes, and most operators use more than one. (1) Email notifications, configurable per user, per severity and per turbine — the default, and enough for most teams. (2) The Turbit web app, where each finding arrives as an EventCard: the plot, a plain-English narrative, a root-cause prediction and a recommended action. (3) Our API, which exposes every alert so you can push it into your own ticketing, reporting or asset-management stack. Detection latency is under four hours from the data point that triggers an alert, so whichever route you use, the finding reaches you the same day.

Not as a native, pre-built connector into each AMS — we expose alerts through our API and you decide where they land. That is deliberate: teams differ on whether a Turbit finding should open a ticket, update an existing work order, or sit in a review queue first, and a connector that guesses wrong creates noise in the system you rely on. If you want alerts flowing into your AMS or ticketing tool, the API is the route, and it is a small piece of work on your side rather than a Turbit project.

Standard interfaces are quick: OPC (DA/UA), IEC 61400-25, IEC 61850/60870, Modbus, SQL database access, or file-based exports over FTP or email. Where we connect to an AMS rather than the turbines directly, we read from the platform you already run. A custom or unusual protocol is usually a few days of work. What we need from you is read access to SCADA data — Turbit never issues control commands, so there is no interaction with turbine control and no warranty implication.