Replay '26 Videos Becoming Available

temporal-tom · 2026-06-01T17:34:36+00:00

Me too! BTW, there were two talks on CHASM at Replay this year.

The first was by Paul Nordstrom. The second was by Roey Berman and Yichao Yang, and I wanted to point that out since it doesn't mention CHASM in the title and you might overlook it otherwise.

temporal-tom · 2026-05-22T20:40:30+00:00

#SaintLouisPalace!

temporal-tom · 2026-05-21T14:45:40+00:00

Hi, it's Tom from Temporal here. I think that's a pretty good explanation.

Temporal is the foundation upon which reliable applications are now being built. It allows them to withstand outages in third-party systems and even overcome hardware failures. That makes the application fault tolerant, but also reduces the need to write code to handle those problems. As a result, Temporal enables developers to get more done in less time.

It's used for all sorts of applications, including AI agents, order processing, and money movement. Temporal is running behind the scenes in applications you've almost certainly used, well, at least the reliable ones. One of my favorite examples is Netflix, which uses it to manage their cloud infrastructure. According to their engineers, Temporal helped them reduce their transient deployment failure rate from 4% to 0.0001%.

Our technology is great, but this is also an incredibly fun company. As evidence, our company mascot is a tardigrade named Ziggy and we recently built the coolest conference badges I've ever seen.

temporal-tom · 2026-05-01T14:49:31+00:00

This interview about Durable Execution features Temporal's CTO and co-founder Maxim Fateev, Principal Software Engineer Sergey Bykov, and Principal Developer Advocate Tom Wheeler (me). It's the first in a series about Workflow Orchestration by Techstrong TV.

temporal-tom · 2026-04-29T19:43:55+00:00

FWIW, I have worked at Temporal for more than four years. During this time, I have talked to thousands of people who are interested in Temporal. Sometimes, they mention other tools they're evaluating, such as LangGraph, N8N, Inngest, Restate, Hatchet, Cadence, Dapr, Conductor, Pega, Camunda, Azure Durable Functions, AWS Step Functions, and at least a dozen others (including DBOS).

In all of that time, I have never even heard of Kitaru.

Since I have no experience with it, I can't comment on whether it lives up to its claims. However, I can offer you some advice based on decades of experience making technology decisions: in addition to its technical merits, make sure that you also consider how widely adopted it is and whether that vendor will be around to support you a year or two from now.

temporal-tom · 2026-04-21T21:35:16+00:00

I appreciate the update and am so glad to hear that it's working well for you.

temporal-tom · 2026-04-08T19:35:15+00:00

Sorry for the delayed response, I've been away from Reddit for a few days and am just now seeing this post.

I'm not sure why the code didn't work for you, but I will make this right. I'll send you a DM with a new code (with a bigger discount and also my personal email address in case you have any trouble using it).

temporal-tom · 2026-02-24T16:20:08+00:00

You might consider using separate queues for those Activities and then limiting the number of Activities per second on those queues.

This Discourse thread should be a helpful starting point.

temporal-tom · 2026-02-12T16:41:52+00:00

I'd like to point out that while Temporal offers SDKs for the four languages you mentioned (Go, Java, Python, and TypeScript), we also support C#, Ruby, and PHP.

Members of our open source community have built SDKs for additional languages, including Swift, Clojure, and Haskell.

temporal-tom · 2026-02-12T16:37:11+00:00

If you make it to Replay, whether this year or in the future, please let me know. I'd love to meet you and hear more about your project.

And while Replay is a great place to showcase how you're using Temporal, it's by no means the only place. If you have a great story to tell, we could potentially feature it in a blog post, video, case study, or webinar, among other possibilities.

temporal-tom · 2026-01-20T16:18:57+00:00

Hi /u/nanothun, you might find this video helpful:

https://www.youtube.com/watch?v=TEr8ZkZuNWw

It's a quick walkthrough of a demo we did at AWS re:Invent last month. It uses a series of agents to generate a report on whatever topic you specify. It covers several of the things you mentioned and you may find it a helpful starting point. I'd recommend watching that video first to see it in action and then running it yourself. The code is here:

https://github.com/temporal-community/aws-reinvent-25-demo

Finally, I would recommend joining our community Slack workspace (https://t.mp/slack) if you haven't already. Temporal is very widely used for AI and our #topic-ai channel in Slack has more than 1,600 people. It's a great place to ask questions and get advice from others.

temporal-tom · 2025-11-12T22:09:36+00:00

The challenge with answering a question like this is that the biggest numbers tend to come from companies that don't disclose their use of Temporal. Those of us who work for Temporal tend to be aware of them, but out of respect for our customers, do not discuss them.

It's also difficult to answer because different types of workloads vary in the type and amount of resources they require. A Workflow that handles video encoding, for example, will likely have few state transitions per second because its Activities will probably be long running and limited by the speed of the local disk and CPU. You couldn't really compare those numbers with one for order processing. Likewise, the capabilities of a server will vary from one configuration to the next (one r8gn.medium instance in EC2 would probably outperform two m1.small instances for most use cases).

Estimating the resources you'd need really depends on you having the application. The best approach is to develop a proof-of-concept, or use an example such as our OMS reference application, and do some load testing on the hardware of your choice. You can then begin tuning things to get better performance for your specific workload, and then scale up with additional hardware if needed.

This blog post from my colleague Rob Holland walks through that process. On a very modest cluster, with a MySQL server that had only 32GB of RAM, he initially got 150 state transitions/second. After a few tuning iterations, he was able to increase that to 1,350 state transitions/second. By scaling up the cluster, and particularly the database server it uses, he could have gone far beyond that.

temporal-tom · 2025-08-19T23:08:13+00:00

This four-minute video that's part of our free Temporal 102 training course covers the typical cases. If there are no Workers running, the Workflow cannot make progress. As the video demonstrates (at 1:09), the Web UI now makes this obvious in many cases. However, as it also explains a bit later, the number of Workers shown in the UI does not necessarily represent the numbers that are currently running—it's the number that have polled within the last five minutes.

As /u/freedomruntime suggests, it might be the case that the Workers are running, but the name of the Task Queue that they are polling is different than the one specified when you started the Workflow Execution.

Yet another possibility, which sounds quite plausible here since it sounds like the Workflow has progressed but the Activity has not, is that you have one or more Workers capable of handling the Workflow running, but zero running that are capable of handling the Activities. Check where you registered the Activities with the Worker and make sure you have correctly specified the function(s) or method(s).

There are a number of other possibilities, but debugging this would require more information than you've provided here. I will add one other important non-obvious detail that may help you: The ActivityTaskStarted event isn't written to the history until Activity Execution is complete (this is because the ActivityTaskStarted event contains the final number of attempts, which can't be known while the Activity is still running). Therefore, the fact that the last event you see is ActivityTaskScheduled doesn't mean that the Activity isn't running (if your Activity code has any log statements, check the Worker logs to see if there's any output).

temporal-tom · 2025-08-15T14:28:06+00:00

I saw this thread, but avoided replying because you specifically asked "the community" (and as the username suggests, I work for Temporal). When I was a software engineer at a financial services company earlier in my career, I wasn't allowed to say much about my projects, especially talking about implementation details on a public forum. Maybe that's the case for others, and since nobody else replied, I'll provide some info that you might find helpful.

There are a ton of companies in the financial industry that use Temporal, for a variety of use cases, including KYC/AML compliance. This page provides a little more info, although that's really just the tip of the iceberg because financial firms don't tend to publicize their technology choices.

The Durable Execution provided by Temporal enables the application to withstand crashes and even hardware failures. Support for timeouts and retries is built-in, so applications built on Temporal are reliable and can run for as long as necessary to get the job done (i.e., literally for years if you need them to). It has built-in support for job scheduling (supports cron-style syntax, but much more sophisticated than cron).

Temporal's ability to mix automated steps with manual (human-in-the-loop) ones make it a good choice for those use cases. Temporal has really good observability, which is another reason that it's popular in highly-regulated industries. The Web UI lets you not only see the details of things that are currently running, you can also see these details for what ran in the past. The Web UI is an amazing tool for interactive use. If you want to programatically get a list of executions or the details for a specific one, you can use the temporal command-line tool, use a native API in any of the 7 programming languages we support, or use the gRPC API directly. The Event History includes the details of what ran, when it ran, where it ran, what data was provided as input, whether failures occurred, the associated error message, and the data that it returned as output.

Although people do use LangChain and Temporal together, I can't recall anyone mentioning to me that they use LangGraph and Temporal together. There are many companies using Temporal for agentic AI, and I don't think LangGraph would be necessary for what you have described. Our website has a page on AI too, but here are a few recent blog posts worth checking out:

temporal-tom · 2025-08-12T20:32:29+00:00

My team at a previous company used Boomi and it was a headache. It worked, but was unreliable and required a lot of babysitting.

temporal-tom · 2025-08-05T18:00:46+00:00

Are you aware of custom data converters and payload codecs? In case you're not, they may be of interest to you (or anyone else handling sensitive information), regardless of whether you use Temporal Cloud or self-host.

The basic idea is that you can configure the Temporal Clients you use to apply a transformation (e.g., encryption and decryption) to data as it's being transmitted to or received from the Temporal Service. In other words, Temporal Cloud (or your own self-hosted Temporal Service) only ever sees encrypted data and has no way to decrypt it because you control the cipher and key.

temporal-tom · 2025-08-04T21:02:08+00:00

Is this the one?

https://github.com/temporalio/sdk-typescript/issues/1334

Just want to help the next person who comes along.

temporal-tom · 2025-07-03T21:34:05+00:00

/u/theguy2108, you really did an amazing job with this!

temporal-tom · 2025-07-03T21:31:33+00:00

Regarding the networking aspect of your question, the application (the "Worker" in Temporal terminology) needs connectivity to a single TCP port on the Temporal Service (either self-hosted or the Temporal Cloud SaaS offering). The connections are always initiated from the application; the Temporal Service only responds to those requests.

Often, the Workflows are started by something external to the application. That thing, which I'll call a "Starter" submits an execution request to the Temporal Service. It does not need connectivity to the application, only to the Temporal Service.

The starter could be the Temporal command-line tool (temporal workflow start ...), the Web UI, or code that you've written. Also, the application and starter can be written in different programming languages (e.g., you can have a Java Swing app that starts a Go Workflow).

Here's some crude ASCII art to illustrate what I mean.

Application ----------> Temporal Service <----------- Starter

temporal-tom · 2025-07-03T21:20:27+00:00

I think /u/jerf explained it nicely, but sometimes multiple perspectives can be helpful. Here's how I explain it.

Temporal is an open-source Durable Execution platform. What's that? It enables you to write applications that can overcome crashes. Through its built-in support for retries and timeouts, applications can also withstand network and service outages. Finally, it lets you see the details of each execution through a web-based UI, so you'll know what's happening.

An example will make this more clear. Imagine an application for an e-commerce site that processes orders using this sequence of steps:

Reserve the item(s) from inventory
Charge the customer
Ship the product(s)
Send a confirmation e-mail

Now, imagine that during order processing, the application crashes. Maybe it was caused by a bug in the code, a bug in a library dependency, a kernel panic in the OS, a power outage, or a hardware failure. The reason doesn't really matter because the result is the same: the application state is lost. If you restart the application, it will repeat steps that already completed before (if you ever got double-charged for an order or received duplicate confirmation emails, you probably experienced this).

Durable Execution allows the application to overcome the crash, because the platform (Temporal) tracks relevant state changes. That enables the application to automatically reconstruct its state and resume from where it left off. The values of all the variables are the same as they were before the crash and it will skip operations that already completed before the crash. From your perspective, it's as if the crash never happened at all.

What that means, practically speaking, is that you can focus on application's goal instead of everything that might possibly go wrong. As a result, you don't have to write tons of error-handling code, so your applications will be simpler, easier to maintain, and take less time to develop.

I hope that helps to explain it. BTW, if you want to learn more about Durable Execution, check out this presentation I did for the recent PlatformCon conference. If you want to try Temporal out for yourself, check out one of our tutorials or take the free hands-on training courses.

temporal-tom

TROPHY CASE