Temporal Cloud Reviews & Product Details

The sheer peace of mind. Once you actually get your workflows written and running, the reliability is night-and-day compared to rolling your own orchestration or duct-taping SQS queues and cron jobs together. The Temporal UI is a lifesaver for debugging—being able to actually look at a failed run, see where it choked, and know it will resume safely from the last step without re-running finished work feels like magic the first few times you see it. Moving the maintenance and cluster-scaling overhead over to a managed cloud service is also a huge win for a small team. The ability to integrate AI flows seamlessly on top is pretty neat too! Review collected by and hosted on G2.com.

The learning curve is genuinely steep. Coming into Temporal, you have to completely re-wire how you think about state, determinism, and code structure. Also, some of the day-to-day DX (developer experience) in the UI or log retention quirks can feel a bit restrictive when you’re deep in the weeds troubleshooting an edge case. Documentation is massive and thorough, which is great, but it can take a lot of hunting to find the "idiomatic" way to solve a specific problem. Review collected by and hosted on G2.com.

One of the features of Temporal Cloud that I found valuable, is it supports recovery and continuation of workflows when an individual step fails without manual intervention to restart the entire process. This comes handy, for instance, when we have applications that require multiple services to work in conjunction with each other. The execution history really helps when troubleshooting what went wrong. Review collected by and hosted on G2.com.

It takes some time to get a sense of how to scope your workflows appropriately, especially if you come from a background of more classic background jobs. Similarly, debugging can be slightly awkward when you have a large workflow, and more descriptive failure messages would help teams with larger deployments. Review collected by and hosted on G2.com.

The application code doesn’t really care where the server is hosted. We ran the same worker and workflow against our self-hosted server and against Temporal Cloud, and the only change we needed was in the connection settings.

Getting started with self-hosting was quick. The auto-setup image created its schema in the Postgres instance we already had (two databases, 39 tables in the main one and 3 for visibility, about 19 MB after a few runs), and the Web UI came up alongside it in its own container.

Temporal Cloud, on the other hand, describes itself through its Ops API: a regional gRPC address for API keys, a separate host for mTLS, the web address, and a limit of 500 actions per second on the namespace. We configure our workers based on that information and nothing else. Review collected by and hosted on G2.com.

Distance is the first thing you notice. A single TCP round trip from our machine to us-west-2 took about 370 ms, so a ten-step workflow ended up taking 6.5 to 7.2 seconds on Temporal Cloud, versus about 0.3 seconds on our local server. In practice, each step costs roughly two round trips.

The fastest path to self-hosting, the auto-setup image, tops out at server version 1.29.7, while the server itself is already at 1.32. For a production setup, that means using the plain server image, plus separate schema tooling and upgrades that we have to run ourselves.

Temporal Cloud reports its server version only as “cloud,” so trying to compare behavior against a specific self-hosted version becomes mostly guesswork. Review collected by and hosted on G2.com.

I wasn’t sure I’d actually need the update features until I tried them. The approve endpoint can send an update to the running workflow and return the result in the same HTTP request, so the API can reply “approved by lead@ops.ex” instead of “accepted, check back later.” The validator also runs before anything is written. When an intern tried to approve, the update was rejected with my own message (“only ops accounts can approve orders”); I mapped that to a 429, and the attempt never showed up in the workflow history.

Idempotency is just a start option, not a table I have to maintain. I build the workflow ID from the client’s idempotency key and tell Temporal to reuse the existing run on a conflict, so a retried POST came back with the same workflow and the same run ID. Review collected by and hosted on G2.com.

The docs and samples lean heavily toward scripts. For a web app, it’s not very clear where you’re supposed to create the client or how to share it across requests, so I had to work that out myself (FastAPI’s lifespan hook works fine).

Latency also adds up when the namespace is far away. Starting an order took about 330 ms, and every step inside the workflow costs a round trip to the US West Coast. Also, a rejected update leaves no trace in history, which is correct, but if you want an audit trail of refused approvals you’ll need to log those yourself. Review collected by and hosted on G2.com.

The durable workflow execution has been really great because it automatically handles retries, state persistence, and failure recovery without needing any custom logic on our end. The workflow visibility feature gives a very clear real-time view of exactly where each workflow is in its execution at any given moment, which has made debugging and troubleshooting significantly faster. Furthermore, the SDK integration worked really smoothly, which meant our developers were writing and deploying their first production workflows much faster than we expected. Review collected by and hosted on G2.com.

The learning curve around understanding workflows and activities can be a bit steep for engineers who are new to the durable execution model. Having more structured onboarding resources and real-world example templates available from the start would make getting the first production workflows deployed a lot less time-consuming for newer team members. Review collected by and hosted on G2.com.

The best thing overall is the reliability and transparency the platform brings. The platform is smooth and fast enough, and we haven’t had any issues there. We use the Temporal UI a lot for debugging and for observing existing runs, and we find it very user-friendly. It does have a steep learning curve, but the support documentation is quite extensive and helps you build just about any type of solution. Review collected by and hosted on G2.com.

Mainly, the pricing model took us some time to understand because it’s action-based, and at first it was hard to estimate what the cost would be. Integrating it with our existing services also required more setup than we expected, especially around workers. On top of that, there aren’t many AI-based features that actually help, particularly in terms of practical AI assistance. That said, most of this was a one-time effort, and now these areas aren’t very problematic. Review collected by and hosted on G2.com.

We use Temporal at Sagepilot for our customer journey engine. What I like most is being able to keep the journey logic in code, with workflow state, waits and retries handled in the same model. A journey isn't always a quick background job; it can wait for a customer event before moving ahead. Temporal is a good fit for that. Having execution history to inspect also makes it easier to understand where a journey is. With Cloud, we don't have to run the Temporal server infrastructure ourselves, though we still own our workers and application logic. Review collected by and hosted on G2.com.

The learning curve is the main downside. You have to think about deterministic workflow code, activity retries and how changes affect workflows that are already running. For event-driven journeys, signal handling and workflow lifecycle also need care; Cloud doesn't remove that application-level complexity. The execution history is useful, but understanding a long workflow still takes some digging. I'd like clearer guidance around these everyday debugging and deployment cases. It's a good fit for stateful workflows, but I wouldn't use it for every small background task. Review collected by and hosted on G2.com.

I work at a medium-sized software developer organization, and we're using Temporal Cloud to orchestrate all our core back-end workflows, chiefly data pipelines dealing with third-party APIs and our complex data pipeline application itself. It's a brain for coordinating state throughout our microservices, which means, if a certain downstream service fails to respond, for example, our long-running task will eventually finish.Managed Temporal Cloud is really cool because the team doesn't need to be concerned with the underpinnings. With our own Temporal implementation, we would have had to deal with a large Cassandra or PostgreSQL database, and other scaling challenges, but that all conditions are completely obscured with the Cloud version and we can focus on only logic for our workflows. The visual dashboard really comes in handy for troubleshooting. In the UI I can hover over a failed activity, view exactly which activity timed out, view the exact history of the whole activity, even restart the process from where it failed. The built-in retries are outstanding and really eliminate the need to have thousands of lines of error handling code. Review collected by and hosted on G2.com.

Once you're starting to write your workflows, you know it's a steep learning curve. You need to understand and create deterministic code which can be quite a fumble for the junior guy who isn't used to this type of event driven coding. From the cloud platform side, the way in which they're charging you for the cloud platform services depends on state transitions and actions and that's not quite as easy to see your month's cost for your various workloads until you've deployed your workloads into production. Also, the web UI could be improved, there are no advanced options to search for specific historical workflows and the Log Retention Period seems too short when doing in-depth investigation into an issue that occurred a few days ago. Review collected by and hosted on G2.com.

What amazed me about Temporal Cloud was how cleanly it replaced the brittle state-tracking tables and custom retry loops I used to maintain in our SQL databases. On our DPU UK & CEE Apps, I work on multi-step background processes where C# (.NET) services validate regional business rules and trigger Python workers to sync records into Qchex. Previously, if a downstream API timed out halfway through a batch, I had to manually reconcile half-completed database rows during maintenance windows. Moving those pipelines to Temporal Workflows and Activities changed everything, because the SDKs automatically persist the Event History at every step so a crashed worker or network blip simply picks up from the exact point of interruption without duplicating transactions. Personally, jumping into the Temporal Web UI timeline view and using the tcld CLI to inspect live input payloads and stack traces has saved me hours of debugging every sprint. Review collected by and hosted on G2.com.

The steepest hurdle for me and our team was getting used to Temporal's strict deterministic execution rules during Workflow Replay. When I first migrated some of our legacy C# services, I accidentally left a standard system clock call and a direct database query inside the Workflow definition instead of isolating them inside Activities, which threw non-determinism errors during testing. Setting up Worker Versioning when I roll out breaking changes to long-running .NET workflows in our CI/CD pipeline also requires careful upfront planning. Additionally, hitting the default 2MB payload limit meant I had to write a custom data converter to offload large Python batch payloads to Azure Blob Storage before passing references between steps. Review collected by and hosted on G2.com.

Temporal Cloud is something I enjoy using when I need to complete certain tasks. In my experience working with backend systems, I’ve found that Temporal lets you run these actions with retries and built-in fail-safes, which makes the overall workflow more dependable. It’s a great tool if you’re using applications with multiple microservices and you need reliability across them. Review collected by and hosted on G2.com.

It can be difficult to learn at first once you really get into it. However, once you understand what workflows and activities are, and how they fit into your application, it becomes much easier to use. There’s also a bit of a learning curve in the thought process behind setting up workflows for your application, since you need to plan how everything should be structured. If your application isn’t too big, you may not need these extra features. Review collected by and hosted on G2.com.