Predictive Maintenance on Google Cloud (GCP)

If you have been asked to put a predictive maintenance programme on Google Cloud, this is the article I would hand you before the first architecture workshop. It walks the stack layer by layer, names the Google Cloud services that sit in each layer, and is candid about the one structural gap that makes Google's story different from its competitors: there is no longer a dedicated managed IoT front door, so device connectivity is a decision you have to make deliberately rather than a box you tick. Everything else in the stack is strong, and in the analytics layer it is genuinely excellent. But the platform is the easy part, and pretending otherwise is how these programmes end up as dashboards nobody opens.

The message up front: choosing and assembling the cloud platform is the least difficult part of predictive maintenance. This article describes how to assemble it well on Google Cloud. It is not a claim that assembling it will make the programme succeed. What decides success is asset selection, data quality, detectable failure modes, and whether a prediction becomes a work order in the system your technicians already use. For that judgement, start with the predictive maintenance practitioner's guide, not with a cloud console.

1. The honest framing before any architecture diagram

I have sat in a lot of meetings where the predictive maintenance conversation opened with a cloud vendor logo. That is the wrong starting point, and it is worth saying so plainly at the top of a cloud architecture article, because the rest of this piece is only useful once the framing is right.

A predictive maintenance programme has roughly five hard problems. Which assets deserve monitoring at all. Whether their dominant failure modes give any detectable warning. Whether the maintenance history is clean enough to learn from or measure against. Whether the organisation has the reliability engineering discipline to act on a signal. And whether the workflow closes, so that a model output becomes a scheduled, executed, closed-out job. The cloud platform is the sixth problem, and it is comfortably the easiest of the six. It is also the one that gets ninety percent of the attention, because it is the one that can be solved by buying something.

So read what follows as an assembly guide, not a business case. The architecture below is sound. It will ingest telemetry reliably, store it economically, train models sensibly and write results back into a maintenance system. None of that guarantees that the failure rate moves. I have never seen a predictive maintenance programme fail because the cloud was wrong. I have seen several fail because the assets were wrong, the data was thin, or nothing wrote back to the work order system.

One more framing note. This article stays strictly on Google Cloud. If your actual question is which hyperscaler to choose, that is a different and more interesting question, and it belongs in the cloud platform comparison for predictive maintenance; the equivalent walkthroughs for the other two large platforms are predictive maintenance on Microsoft Azure and predictive maintenance on AWS. I will not compare here beyond that pointer.

A standing caveat that applies to every named service below: Google renames, repositions, folds together and occasionally retires cloud services, and it does so more visibly than most. Product boundaries that are true when this is written may have shifted by the time you architect against them. Treat the current documentation at cloud.google.com as authoritative and this article as a map of the shape of the solution rather than a parts list to order from.

2. The connectivity gap: Google retired its dedicated IoT service

This is the single most useful thing this article can tell you, so it goes second rather than buried in a footnote.

For several years Google Cloud offered a dedicated managed IoT service, Cloud IoT Core, which handled device registration, per-device credentials, MQTT and HTTP device connectivity, and the bridge into the rest of the platform. Google announced that it was retiring that service, and it is no longer positioned as the managed IoT front door for new builds. You should verify the current status and any successor positioning yourself before committing an architecture, because this is exactly the area where Google's messaging has moved, but you must plan on the assumption that there is no drop-in managed device management layer waiting for you.

That matters more than it sounds. In a predictive maintenance build, the device layer is not a rounding error. It is device identity, per-device certificates and rotation, provisioning of thousands of sensors, firmware and configuration push, connection state and last-seen tracking, MQTT topic structure, and offline buffering behaviour. On a platform with a managed IoT service, most of that arrives as product. On Google Cloud today you choose between three broad paths:

• A partner or third-party device management product running on or alongside Google Cloud. Several industrial IoT and device management vendors positioned themselves explicitly to fill this space after the retirement announcement. This is the shortest path to managed-feeling device connectivity, at the cost of a commercial relationship and another vendor in the critical path.
• An open-source broker you run yourself, typically an MQTT broker on Google Kubernetes Engine or Compute Engine, publishing onward into Pub/Sub. You keep full control of topic design and device credentials, and you own the operational burden: high availability, certificate lifecycle, patching, scaling and monitoring. For a plant with a modest and stable device population this is entirely reasonable. For tens of thousands of geographically dispersed devices it is a real engineering commitment.
• Direct ingestion into Pub/Sub from an edge gateway that holds the service credentials, rather than from individual devices. In most industrial settings this is the pattern I would reach for first, because the sensors are usually not internet-connected devices anyway: they are wired or wireless field devices behind a gateway, a PLC, a SCADA system or a BMS. The gateway becomes the single authenticated publisher, and device identity is handled locally rather than in the cloud.

The good news is that for most industrial predictive maintenance work, the third option is closer to the reality on the ground than the vendor diagrams suggest. Plant instrumentation rarely speaks directly to a cloud. It speaks Modbus, BACnet or OPC UA to a gateway or a historian, and the cloud conversation starts there. If that is your situation, the retirement of the dedicated IoT service costs you very little. If you genuinely have a fleet of independently connected devices in the field, it costs you a great deal, and you should know that before you choose.

3. Where Google Cloud is genuinely strong for this workload

Having led with the gap, it is only fair to be equally clear about the strength, because Google Cloud is chosen for this workload for good reasons.

BigQuery is the reason most teams end up here. As an analytics store for large volumes of maintenance and sensor history it is unusually good: serverless, separating storage from compute, comfortable with very wide and very deep tables, strong at the kind of windowed, time-ordered SQL that condition analytics is full of, and pleasant to hand to an analyst who knows SQL but not Spark. It supports partitioning and clustering on time and asset identifiers, which is exactly the access pattern telemetry analysis needs. It also has native machine learning through BigQuery ML, which lets you train and evaluate certain model classes with SQL against data already in place, and that is a genuinely useful shortcut for early anomaly and regression work when you do not yet have a data science team.

Vertex AI is a coherent machine learning platform rather than a collection of loosely related services. Training, tuning, a model registry, managed endpoints for online inference, batch prediction, pipelines for orchestration, feature management and monitoring sit in one product with one mental model. For a predictive maintenance team that will eventually need reproducible retraining and versioned deployed models, that coherence is worth a lot more than it appears on an architecture diagram. Model drift and retraining discipline are where these programmes quietly decay, and a platform that makes the lifecycle explicit helps.

Pub/Sub and Dataflow are a mature streaming pair. Pub/Sub is a globally available managed message service with straightforward at-least-once delivery semantics, and Dataflow, built on Apache Beam, handles both streaming and batch with the same programming model, which means one codebase for the live path and the backfill path. That symmetry matters more in practice than it sounds, because telemetry pipelines spend a lot of their life reprocessing history after a schema or calculation change.

4. The reference architecture, layer by layer

Every predictive maintenance platform, on any cloud, has the same seven layers. What changes between platforms is which product occupies each one. Here is the shape:

And here is the layer-to-service mapping in the form I would put in front of an architecture review board. Read the last column as the thing that actually decides whether the layer works, because that is usually where the argument should be.

Two notes on that table. First, Cloud Run and Cloud Functions overlap considerably and the boundary between them has moved; for the integration layer I now default to Cloud Run because a containerised service is easier to test locally and easier to move later, but a small Cloud Function is perfectly adequate for a single write-back handler. Second, Looker and Looker Studio are different products with a shared name, which confuses newcomers: the former is a governed semantic modelling and BI platform, the latter a lighter self-service reporting tool. Both can read BigQuery directly.

5. The edge decision and what belongs there

The edge question in a cloud architecture is really a question about what you refuse to send. High-frequency vibration data in particular cannot sensibly be streamed raw to a cloud for a large asset population. The bandwidth, the ingestion volume and the storage all become unreasonable long before the analytics get interesting.

The pattern I would recommend is that the edge computes features and the cloud learns from them. A gateway sampling a vibration sensor at high frequency should compute the derived values that reliability engineering actually uses, overall amplitude, band energies, kurtosis, peak values, and forward those at a manageable interval, while retaining raw waveform snapshots only around anomalies or on demand. That single decision usually reduces the volume reaching Pub/Sub by orders of magnitude without losing diagnostic value.

The edge also earns its place for protocol translation from Modbus, BACnet or OPC UA, for store-and-forward buffering across connectivity outages, for local safety-critical logic that must not depend on a cloud round trip, and for the initial filtering of clearly invalid readings. What does not belong at the edge is model training, cross-asset comparison, or anything that needs the full history. That is what the cloud is for. The full trade-off, including when to push inference itself to the edge, is covered in edge versus cloud for predictive maintenance, and the sensor selection side in IoT sensors for predictive maintenance.

6. Time-series storage: BigQuery, Bigtable, or both

This is the design question that generates the most debate in Google Cloud predictive maintenance builds, and the answer is usually both, for different jobs.

BigQuery is where analysis lives. It is columnar, serverless and built for scanning large ranges: give me every reading for this pump class for the last two years, aligned to the work orders raised against those pumps, windowed by day. That is the query pattern of reliability analysis and of model feature engineering, and BigQuery is excellent at it. Partition by ingestion or event time and cluster by asset identifier, and it stays fast and economical as the table grows. It is also where your maintenance history from the CMMS or EAM should land, because joining telemetry to work order history is the whole point.

Bigtable is where you go when the access pattern is narrow and latency-sensitive: give me the last N readings for this one asset, right now, in single-digit milliseconds, at high write throughput. If you are serving a live operator screen across thousands of assets, or feeding an online inference endpoint with a recent window, Bigtable fits. Its cost is design rigidity: performance is determined almost entirely by row key design, typically an asset identifier combined with a reversed or offset timestamp, and getting that wrong creates hotspots that are painful to fix afterwards because the key cannot simply be altered later.

The trade-off in one line: BigQuery is cheap to query broadly and comparatively slow for a single point lookup; Bigtable is fast for point and narrow-range lookups and poor at broad analytical scans. Many teams start with BigQuery only, which I think is the right default, and add Bigtable only when a genuinely latency-sensitive serving requirement appears. Adding a second store before you need it is a common way to double the operational surface for no benefit.

7. The modelling reality: anomaly detection first

I am not going to re-teach predictive maintenance modelling here; the theory is covered in the machine learning for predictive maintenance guide and the remaining-useful-life side in from RUL to FMEA. What belongs in a Google Cloud architecture article is how that reality shapes what you build on the platform.

The dominant constraint is label scarcity. Supervised failure prediction needs examples of assets that ran to failure, correctly labelled, with the telemetry that preceded each failure. Almost no organisation has that in usable quantity. Work orders say "bearing replaced" without a precise failure onset time, downtime is recorded inconsistently, and the assets that fail most are often the ones with the least instrumentation. This is not a cloud problem and no platform solves it.

So the sequence I would recommend on Vertex AI and BigQuery ML is deliberately modest:

• Start with unsupervised anomaly detection. Learn what normal looks like for an asset from healthy operating data and flag deviation. It needs no failure labels, which is why it is the only honest starting point for most sites. BigQuery ML can carry a good deal of this without leaving SQL.
• Add statistical and threshold logic alongside, not instead. Engineering limits and trend extrapolation are transparent, trusted by reliability engineers, and deliver a large share of the achievable value. A model that an engineer cannot reason about will not be acted on.
• Build the label capture loop early. Every anomaly you raise and every work order it produces is a potential future label, if and only if you capture the outcome: was the anomaly real, what was found, when did the degradation actually start. Instrument that from day one and in two years you have a supervised training set. Skip it and in two years you have the same label scarcity.
• Treat remaining useful life as a later phase. It needs run-to-failure histories across a fleet of comparable assets. Promising RUL numbers in phase one is how credibility gets spent before it is earned.

On serving: most maintenance predictions do not need online inference. A scheduled batch scoring job that runs hourly or daily over the latest window, using Vertex AI batch prediction or a BigQuery ML prediction query, matches how maintenance planning actually operates and costs far less to run and operate than a permanently provisioned endpoint. Reserve online endpoints for the genuinely real-time cases.

8. The last mile: writing a prediction into the CMMS

This is the layer that decides whether the whole architecture was worth building, and it is consistently the least funded. A prediction that surfaces as a Looker tile or an email is a prediction that will be ignored within a few weeks. The only output that changes anything is a work order, in the maintenance system the technician already opens every morning, carrying the asset, the symptom, the evidence and a priority.

The pattern I would build: the model output lands on a Pub/Sub topic, a Cloud Run service subscribes, applies the business rules, and calls the maintenance system's API to create a work order or a condition-monitoring notification. The rules matter as much as the call:

• Suppression and deduplication. An anomaly that persists for six hours must not create six work orders. Keep a state store of open predictions per asset and only raise once until the condition clears or escalates.
• Idempotency. Carry a deterministic external reference on every write so that a retry after a timeout does not duplicate. Pub/Sub delivers at least once, so your handler must be safe to run twice.
• A confidence threshold and a severity map. Not every anomaly deserves a work order. Low confidence should raise an inspection task or a watch-list entry; high confidence on a critical asset should raise a prioritised corrective job.
• Outcome capture back into BigQuery. When the work order closes, pull the findings and failure codes back. This closes the learning loop and is the only way you will ever get labels.
• A dead letter path and alerting on the integration itself. If the write-back is failing silently, the programme is dead and nobody knows. Monitor it as a production integration, not as a script.

Whether you write through a REST API, an integration platform, or a staging table depends entirely on the target system. IBM Maximo, SAP PM, Hexagon EAM, Planon and the mid-market tools such as Fiix, Limble, MaintainX, UpKeep and eMaint all expose different surfaces with different appetite for machine-created work orders, and some of them have opinions about which object type a condition alert should become. The general integration patterns are covered in IoT integration with CMMS, and if the maintenance system itself is moving to the cloud at the same time, migrating CMMS and EAM to the cloud is the relevant companion.

9. The OT/IT boundary, identity and residency

Plant floor data does not simply flow to a cloud, and the assumption that it will is the most common reason these projects stall after the architecture is approved. Control networks are deliberately segmented, often following a zone and conduit model, and the operations team that owns them is accountable for plant availability and safety. Their default answer to a new outbound connection is no, and it is a defensible no.

What tends to get agreed is a data diode or a tightly controlled one-way path: a gateway or historian in a demilitarised zone, initiating only outbound connections, publishing a defined and reviewed set of tags, with no inbound path from the cloud into the control network under any circumstances. Design for that from the start. In particular, do not design a write-back that reaches into the control system; the write-back goes to the maintenance system on the enterprise side, which is a different network and a different conversation.

On identity, the discipline is ordinary but worth stating. Service accounts per workload rather than one shared account, IAM scoped to the least privilege each component needs, Secret Manager for the CMMS credential rather than an environment variable pasted into a deployment, and VPC Service Controls where you need a perimeter around the data services so that an over-permissioned identity cannot exfiltrate to a project outside your organisation. Audit logging on, and reviewed.

On residency, the question is simply which region, and it is often decided for you. Google Cloud regions and their available services are not uniform, and a newer service may not be present in the region your regulator, your client contract or your public sector customer requires. Verify service availability in the specific region before designing, not after. For operators in the Gulf, where I work, this is a live consideration on almost every engagement: data residency requirements and sector-specific rules frequently constrain the region, and the region then constrains the service list. Confirm the current regional picture on the Google Cloud site rather than assuming parity.

10. Cost drivers, described structurally

I will not quote prices, because they change and because the useful thing is knowing which dials move the bill. On this platform the drivers are:

• Ingestion volume. Pub/Sub cost scales with the data you publish and deliver. This is the dial the edge feature-extraction decision controls, and it is the cheapest optimisation available.
• Streaming compute. Dataflow jobs are long-running workers. A streaming pipeline is a continuous cost whether or not anything interesting is flowing through it.
• Analytics query cost. This is the one to understand properly, below.
• Storage tiers and lifecycle. Cloud Storage classes and BigQuery's cheaper long-term storage both reward an explicit lifecycle policy. Raw telemetry that nobody has queried in a year should not be sitting in hot storage.
• Training versus inference compute. Training is bursty and often accelerator-backed; inference is either a scheduled batch job or a permanently provisioned endpoint. A provisioned endpoint left running for a workload that only needed daily scoring is the most common avoidable line item I see.
• Egress. Data leaving the platform, or crossing regions, is charged. Cross-region architectures acquire a cost that single-region ones do not.

The specific surprise worth planning for: BigQuery's default billing model charges for the volume of data a query scans, which behaves very differently from provisioned compute. A badly written exploratory query against an unpartitioned telemetry table can cost more than a day of a small virtual machine, and a scheduled dashboard refreshing on a wide unfiltered query will do that repeatedly and quietly. Three mitigations. Partition and cluster properly so that queries prune. Materialise the aggregates your dashboards actually read, rather than letting Looker Studio scan raw telemetry. And consider the capacity-based, slot-oriented commitment model once your usage is steady, because it converts an unpredictable per-query bill into a predictable provisioned one. Which model suits you is genuinely a function of how spiky your analytics are, and you will only know that after a few months of running.

Set budget alerts and label every resource by workload from the first day. Retrofitting cost attribution across a sprawling project after six months is miserable work.

11. A staged build sequence that delivers before any model exists

The sequence matters more than the service choices, because it determines whether the programme survives long enough to get to modelling. Each phase below should produce something a maintenance team can use, on its own, even if the next phase never happens.

Notice that phase 0 requires no cloud ingestion at all and frequently returns more than phases 3 to 5 combined. Notice also that phase 2, the unglamorous threshold phase, is what makes everything after it possible, because it builds the write-back integration and starts capturing outcomes. Teams that jump straight to phase 3 or 4 arrive with a model and no route for its output, and the model quietly stops being looked at.

If you are also evaluating whether to buy a packaged product rather than assemble this, that is a fair question and often the right answer for a smaller estate; see predictive maintenance software and platforms compared and cloud-based asset management software. Building a custom platform on Google Cloud makes sense when your asset population is large, your analytics estate is already here, and the questions you need answered are specific to your equipment. It rarely makes sense for a few dozen assets.

The idea to walk away with

Google Cloud assembles into a capable predictive maintenance platform, and its analytics and machine learning layers are among the strongest reasons anyone chooses a cloud for this workload. BigQuery is an excellent home for maintenance and telemetry history, Vertex AI is a coherent place to run the model lifecycle, and Pub/Sub with Dataflow is a mature ingestion and processing pair.

The two things to plan for deliberately are the connectivity layer, because the retirement of the dedicated managed IoT service means device connectivity and management is a decision with three real answers rather than a product you switch on, and the write-back layer, because an architecture that ends in a dashboard produces no maintenance decisions and therefore no value. If your sensors already sit behind a gateway or a historian, the first of those costs you little. The second costs the same on every platform and is skipped on almost all of them.

Final thoughts

The reason I open a cloud architecture piece with a warning about cloud architecture is that I have watched the platform decision absorb attention that belonged elsewhere. The services in the table above are not the hard part. Choosing the twenty or so assets where prediction genuinely pays, verifying their failure modes have a detectable warning, cleaning the failure coding so the history can be learned from, and building the discipline to act on a signal: that is the hard part, and no region, service or model architecture substitutes for it.

If you are at the start of this, my advice is to spend the first phase in BigQuery with the maintenance history you already own, before a single sensor is specified. It costs almost nothing, it tells you where the investment belongs, and it produces a result you can show a sponsor. Then build phase 2, with the write-back, and only then start modelling. That sequence is unfashionable and it is the one that survives contact with an operating plant.

Related reading: Choosing a cloud for predictive maintenance, Predictive maintenance on Microsoft Azure, Predictive maintenance on AWS, Edge versus cloud for predictive maintenance, Data lakes and lakehouses for maintenance telemetry, IoT integration with CMMS, Predictive maintenance practitioner's guide.