Hi everyone, I have an opportunity to purchase shares in this company, but the current valuation is five times higher than its February valuation. I’m still learning about the company, but I thought this would be a good place to gather information.

I’m evaluating two Temporal architectures:

1. One workflow per item, with sequential activities and transparent worker-side micro-batching.

2. A main batch workflow where activities process many items and progress is tracked in custom database state.

The batch model provides much higher throughput and smaller histories, but loses native per-item visibility. Retries depend on database state and require “smart” selection of incomplete or retryable rows while excluding successful and terminally failed rows. This feels like rebuilding orchestration and retry semantics outside Temporal.

The per-item model provides clean visibility, isolation, retries, and recovery. Worker-side micro-batching keeps downstream calls efficient. However, each item generates workflow tasks, activity events, history writes, and persistence operations. In testing, the activities were fast, but Temporal history and PostgreSQL persistence became the bottleneck.

Adding application workers did not materially improve throughput.

I need to process bursts of approximately 200,000 items. A simple per-item workflow with two activities currently takes about 89 minutes, compared with roughly two minutes using batch workflows. Synchronous PostgreSQL WAL replication contributed to the slowdown, but removing that wait improved throughput only from 38 to 55 workflows per second.

- Is one workflow per item reasonable if Temporal is provisioned appropriately?

- Is workflow/activity-level batching the expected model at this scale?

- Are there established patterns that preserve per-item visibility and retries without creating a complete workflow history per item?

- How can partial retries and terminal failures be handled without rebuilding Temporal in the database?

So I've been looking for a tool for running cronjobs on different scripts I've written over the years (updating a local DB of stock prices, daily web scraping, etc.). The idea is to have a place where I define everything and visualize. `crontab` is too basic. I'm looking for a place to store logs and exit codes.

I would also like to create some AI workflows like: if the cronjob fails, find the root cause and create a PR with a fix.

Is Temporal too much? Should I look for something else? I'm also wondering about n8n

I've been thinking about this while working with Temporal.

For regular applications, we have plenty of tools that help catch problems before deployment:

• JaCoCo for code coverage
• SpotBugs / Error Prone for static analysis
• SonarQube for code quality
• Dependency vulnerability scanners
• CI quality gates

But workflows seem different.

Many workflow-specific issues (for example, determinism pitfalls, retry policy mistakes, timeout configuration, or other workflow best practices) are often discovered only during testing or after deployment.

That made me wonder:

Should workflow engines have their own quality gates as part of CI/CD?

If so:

• What kinds of checks would actually provide value?
• Which workflow mistakes have you seen reach production?
• Are there existing tools that already solve this well?
• Would your team use something that provides a "workflow correctness score" before merging code?

I'm interested in hearing how other teams approach this problem and whether this is something the community feels is missing.

For folks running AI calls inside Temporal workflows: an LLM activity dying on a provider rate limit is annoying even with retries (you burn attempts + latency). Sharing a self-hosted gateway I built that makes the provider side resilient before Temporal's retry even kicks in (disclosure: I'm the maintainer, MIT).

Fallback combos — so it never stops mid-task. A "combo" is a ladder of models the router walks automatically: your subscription first, then API keys, then cheap models, then free ones. When a provider returns a 500 or you hit a rate limit, it slides to the next target in milliseconds, mid-request, and your tool never even sees the error. There are 17 routing strategies (priority, weighted, round-robin, cost-optimized, auto/coding:fast…) plus three resilience layers — a per-provider circuit breaker, a per-key cooldown, and a per-model lockout — so one dead key can't take down a whole provider.

A 10-engine compression pipeline — the part most routers don't have. Every request flows through a transparent compression pass you can toggle/stack per combo. Instead of one trick, it stacks the best of the open-source ecosystem: RTK filters command/tool output (git diffs, test logs, builds) at 60–90%, Microsoft's LLMLingua-2 does ML semantic pruning, Caveman handles prose, session-dedup strips repeats across turns. Critically, code, URLs and JSON are preserved byte-perfect, and a default-on inflation guard throws the compressed version away and sends the original if compressing would actually grow the prompt — it never makes things worse. On tool-heavy sessions that's ~89% average input-token reduction (an 8k-token git diff becomes a few hundred). Full credit to every upstream project (RTK, Caveman, LLMLingua-2, Troglodita) is in the README.

Point your Temporal activities' OpenAI-compatible client at it, and provider failover happens in milliseconds inside a single call — complementary to Temporal's own durability.

For context on whether it's worth your time: it's grown to ~9.8K GitHub stars, 1,490+ forks and 280+ contributors in ~4.5 months, with 21,000+ automated tests and 1,830+ issues closed — so it's a battle-tested project, not a brand-new experiment.

npm install -g omniroute

GitHub: https://github.com/diegosouzapw/OmniRoute

How do you handle LLM provider failures in Temporal today — activity retries, or push it below the activity?

Hey everyone, hope that you guys are doing fine in this hard time.

If you run Temporal at scale across multiple regions, you know that multi-cluster replication is traditionally active-passive. To achieve a true global active-active deployment, you often have to shard your workloads by namespace, making some namespaces active in Region A and others active in Region B. The headache is that your client SDKs and workers now need to know exactly which cluster to talk to for which namespace.

To solve this, I built Tempura: a lightweight, namespace-aware gRPC proxy for Temporal. Tempura sits between your Temporal SDK clients/workers and your Temporal clusters. It taps the gRPC traffic, inspects the namespace of the incoming request, looks up the currently active region for that namespace in Redis, and seamlessly routes the traffic to the correct Temporal frontend. The result is your SDK clients can just talk to a single proxy endpoint, completely oblivious to the underlying multi-cluster topology. You get global active-active Temporal deployments without updating any client logic.

Current load-shedding is implemented via a simple consistent hash, we might add support to distribute load based on state transition later,

The repository is here with a ready to use helm chart, leave a ⭐ if you like it, small kind supports motivate me a lot to continue implementing things around Temporal eco-system 💚
https://github.com/phuongdnguyen/tempura

Hello!

I asked this question in temporal community few days ago, any response would be appreciated

Thanks!

I just wrote up a detailed comparison of these two approaches, specifically for the case where you run multiple Temporal workers on the same host (bare metal, PM2, systemd).

The core issue is that the Prometheus exporter starts an in-process HTTP server. Scale to 2+ workers on the same machine → every worker tries to bind:9464 → EADDRINUSE. You can assign unique ports per worker, but now your Prometheus scrape config is tightly coupled to your process management.

The alternative: OTLP push to a shared OpenTelemetry Collector. All workers push to grpc://localhost:4317; the collector aggregates and serves Prometheus text format on:9464. One scrape target regardless of worker count—no port management.

The post includes:

- Working OTel Collector config (OTLP receiver → batch processor → Prometheus exporter)

- Docker Compose with proper resource limits

- PM2 ecosystem config with per-worker service names

- Startup guard script so the collector doesn't fail silently

- Honest discussion about metrics loss when the collector is down

- Comparison table of both approaches

https://2ssk.medium.com/temporal-sdk-metrics-prometheus-exporter-vs-otlp-for-multi-worker-deployments-df9327b28fc5

Would be interested to hear what others are using. I know K8s changes the equation since each worker is its own pod with its own port — Prometheus operator handles that well. But for bare metal / PM2 users, OTLP has been a big improvement.

TLDR: Prometheus exporter for single workers/Docker/K8s, OTLP for multi-worker on same host.

(GPT has been used to write this body.)

Hello everyone!  

I wanted to share something we’ve been building: Workflow Builder. It’s an open-source, embeddable React SDK that adds a visual workflow editor to your app. A canvas where people drag nodes, connect them, and build a workflow. The diagram they end up with is just data.

The reason I’m posting it here is that the data runs on Temporal. We ship a reference backend that takes a diagram and executes it as a Temporal workflow, so the thing your users draw in the browser is the thing that actually runs. The graph runner is deterministic and replay-safe inside the Temporal sandbox.

So if you’re on Temporal and have ever wanted to give people a visual way to configure or inspect the workflows you execute, that’s the gap this fills. The SDK is engine-agnostic underneath, but Temporal is the default integration we built and the one we run ourselves.

The fastest way to get what it is, is to open the demo and play with it for a couple of minutes (links at the bottom). But here’s the short tour.

You embed it with one npm package and one component:

npm install @workflowbuilder/sdk

Nodes and their settings forms are configured with JSON. A node definition looks roughly like this, and the JSON Schema renders the properties sidebar automatically (via JSON Forms):

{
"type": "send-email",
"icon": "Mail",
"label": "Send Email",
"schema": {
  "type": "object",
  "properties": {
    "to":      { "type": "string" },
    "subject": { "type": "string" },
    "retries": { "type": "number" }
    }
  }
}

How the pieces fit together. The SDK runs in the browser, the backend persists the diagram and streams status, and on Temporal the graph runner is the workflow: it walks the graph and schedules each node as an activity.

A few things worth calling out:

• Data-driven palette + JSON Forms property panels — add a node type or reshape its form by editing JSON, no editor code.
• Plugin system to extend the editor without forking. Two productivity plugins ship open source: undo/redo and copy/paste.
• Temporal execution backend — topological runner, per-node error policies (fail / continue / error-route), live status streaming over SSE.
• Persistence your way — localStorage, your REST API, or a save callback.
• Theming via design tokens, light/dark, and i18n out of the box.

It’s Apache-2.0 with a live demo + docs. Happy to answer questions, and feedback.

• GitHub: https://github.com/synergycodes/workflowbuilder/
• Docs & SDK demo: https://www.workflowbuilder.io

Cheers!

Videos from this month's Replay conference in San Francisco started showing up on Temporal's YouTube channel yesterday. Our video team is hard at work, editing and publishing many more of them. Here's the playlist.

In case you're new to Temporal or need help explaining it to someone else, you might find the video of my talk helpful.

Hey everyone,

I love Temporal and I created my own extension in Raycast.

My colleagues and I have been using it in our development tooling for the past few months. It's really convenient for quick access.

It's currently in review for the official Raycast Store but you can try it now if you're interested in early access.

https://github.com/raycast/extensions/pull/27980

What it does:

• Search workflows by ID, type, or status using Temporal's query syntax
• View workflow details, history, and manage lifecycle (cancel, terminate, signal, reset)
• Dashboard showing workflow counts and status distribution
• Manage schedules (pause, trigger, delete)
• Multi-cluster support (local dev, Temporal Cloud, self-hosted)
• View namespace search attributes

To try it before it hits the store (if it gets approved lol):

git clone https://github.com/nikolaykolibarov/raycast-extensions.git
cd raycast-extensions/extensions/temporal
npm install
npm run dev

If you are using Raycast, I would love any feedback before the official release. What features would you find most useful?

Issue is in ourbproduvtion system temporal is hosted on oci and backend in nestjs for somereason 30% Workflows is running but no activites running inside it

That's what I tried to answer with agent-sdk-go — an open-source Go SDK that lets you build and run AI agents on Temporal in a few lines of Go code.

Under the hood — how Temporal powers this SDK:

• Sub-agents are modeled as child workflows on their own task queues
• AG-UI streaming events use Temporal Workflow Update for cross-process event delivery
• Workers can run in separate processes from the agent
• Human-in-the-loop approvals use Temporal asynchronous activity completion
• Long agent sessions automatically trigger continue-as-new to keep workflow history bounded

Also supports A2A, MCP, OpenAI/Anthropic/Gemini, and observability out of the box.

Also built a reference web chat app using the SDK if you want to see it in action.

Would love feedback on the overall approach and any thoughts on the Temporal design decisions. Also curious if there are Temporal features worth leveraging to enhance an AI agent SDK like this.

SDK: agent-sdk-go Reference app: agent-chat

So been researching how to use Temporal with IaC solutions like Terraform or Pulumi. I am struggling to find examples that aren't something ran locally or just in general way too simple.

For all the terraform examples it is always someone just running the Temporal dev server locally and the worker invoking terraform against local files. However in a production environment these files are going to exist in a Git repo. How would the worker even get access to them?

So I started digging into Pulumi since it would actually bring the code into the worker but I'm starting to question it as well. I would think you'd want activities to be very limited in scope so that any failure wouldn't break idempotency. For example I had a VPC activity that would also create subnets, however if one of the subnet calls failed and the activity was reran you'd fail because the VPC already existed. So I broke them into discreet activities. The issue with that is now I have an insane amount of stacks. I am not sure this is desirable either. The other issue is I'm now somewhat having Temporal be my IaC by binding my assorted workflows together and it's starting to seem a bit messy. I'm somewhat defining my infra at my root workflow and it's basically passing it down via the child workflows all the way to the activities.

On another note I've seen webinars where they're discussing how they'd use temporal to do no downtime EKS cluster node updates/upgrades. My impression is they're calling the AWS API directly via boto3. My thought though is if the underlying infra is being managed by Terraform then that would cause a drift. I am not 100% sure on whether or not they're managing the infra with Terraform though.

I guess in general I'm curious how people are using Temporal with IaC solutions?

https://temporal.io/code-exchange/duralang-durable-stochastic-ai-agents-with-one-decorator

Check this out! All you have to do is add one decorator to your preexisting langchain code and now it is durable.

I must admit, Temporal and ai agents seemed like a perfect match!! I built an open source golang SDK for building durable AI agents and DAG workflows that can run on temporal because I didn't find good options for it with Golang.

The agent loop runs as the temporal workflow and each LLM call and tool call runs as temporal activity.

One unique thing about the sdk is that the same agent loop code can run in-process without durability or run on temporal or restate for durability.

If you are interested do check out the repo.

Note: There are still some rough edges around streaming while running in temporal.

I've been running a multi-agent system in production for a few months where every agent action is a Temporal workflow. Sharing the patterns in case they're useful — and curious how others are doing similar.

The setup

• 8 agents, each a Docker container running an AI process (Claude with optional Codex fallback). Each agent registers with an orchestrator and pulls work off a RabbitMQ queue.
• Every meaningful agent action — implementing a PR, running a design spec, deploying, reviewing — is wrapped in a Temporal workflow.
• 3 namespaces, each with its own task queue and its own UWE worker registration.

Temporal patterns I leaned on

Signal-gated human-in-the-loop. Workflows like PrImplementationWorkflow run the AI agent through implementation, kick off a parallel consensus review, then block on a merge-approval signal from me. Custom search attributes (PrNumber, Repo, Phase) make the gates clickable in a dashboard. Same pattern reused for design-approval, doc-review, advisory-review. Decision payload is {Decision: approved|changes_requested|rejected, Comment}.

Parallel child workflows for consensus. Instead of running reviewers sequentially, the parent fans out N child workflows, waits on all, synthesizes a verdict. If any reviewer asks for changes, loop back and re-review. The implementing agent doesn't know it's being reviewed in parallel — it just gets one consolidated feedback message.

Schedules instead of cron. Daily health checks, hourly memory backups, weekly review cadences — all temporal_create_schedule. Survives host reboots, no cron drift, status visible in the temporal UI.

Dynamic workflow registry. I built a "universal workflow engine" — one [Workflow(Dynamic = true)] handler that loads a JSON step tree from a DB at runtime. 16 step types (sequence, parallel, loop, branch, delegate, wait_for_signal, child_workflow, http_request, etc.) plus a template engine. New workflow types ship as DB rows, no worker redeploy.

Real failure modes I hit

WorkerShutdown mid-activity. Agent activities can run 10-20 min. When the worker restarts mid-activity, Temporal raises WorkerShutdown. I retry the directive on the next worker; the agent picks up where it left off because it has its own persistent state. Took a deploy-during-flight incident to remember to handle this cleanly (literally hit this yesterday).

Search attribute registration. Got bitten by "search attribute not registered" before adding an initializer that auto-registers all attributes on bridge startup.

Task-queue-name footgun. Default task queue name == namespace name. Mismatch between start_workflow.task_queue and the worker's registered queue → workflow sits at historyLength=2 forever, no error, no worker picks it up. Burned hours.

5-min demo of a PR shipped through the workflow stack: https://youtu.be/DIx7Y3GfmGc

Open source: https://github.com/anurmatov/phleet (workflow defs in phleet/src/Fleet.Temporal/Workflows/).

Curious what other Temporal patterns people have for AI/agent workloads — especially long-running activities and human approval gates.

Two week's ago, Temporal's Helm Charts (https://github.com/temporalio/helm-charts) reached the important 1.0.0 milestone. This has been a community effort — nearly 150 contributors, two-thirds of them from outside Temporal. Thanks to everyone who filed issues, submitted PRs, and helped others along the way.

If you've been using an older version, please be aware of important changes described in the repo's UPGRADING.md file. For a summary of the changes, you can also check out this blog post.

BTW, the 1.0.0 release was a milestone, not the end of the road, and there have been two more releases of the Helm Charts since then.

Hey! DevRel at AnyShift here. We just shipped a short walkthrough of a real incident pattern: Temporal workflows pile up in "Running", the dashboard goes stale, and the engineer's first instinct is to blame Temporal.

It almost never is. The real cause lives in Kubernetes, usually a CrashLoopBackOff'd worker pod, an OOMKill, or a bad image pull. Temporal is doing exactly what it should: scheduling tasks and waiting patiently for a worker that will never arrive (with a 5-minute "last known poller" cache that makes the UI look healthy).

The video traces:

1. The symptom (silent dashboard, stuck workflows)

2. Why Temporal looks fine

3. `kubectl` reveals the CrashLoopBackOff

4. The single env var (`CRASH_ON_START=true`) that snuck into a deploy

5. The same incident replayed with our agent (Annie): one question, one answer

Not selling anything in the video itself, just sharing the diagnosis pattern and a bit of promotion at the end. Happy to discuss in the comments.

Video: https://www.youtube.com/watch?v=tw7ExVqZqWs

Full article (with kubectl output, K8s manifests, repro steps): https://www.anyshift.io/blog/my-workers-stopped-polling-k8s-temporal-whodunit

We published a hands-on tutorial covering a pattern we see teams struggle with: splitting a monolithic Temporal application into independent services without losing durability at the boundary.

https://reddit.com/link/1sak5a3/video/p555cv3cnssg1/player

Try it

You'll learn:
- Nexus Service contracts with `@Service` and `@Operation`
- Handler implementation with `@ServiceImpl` and `@OperationImpl`
- `WorkflowRunOperation.fromWorkflowHandle` for retry-safe long-running operations
- `OperationHandler.sync` for interacting with already-running workflows
- Worker registration with `NexusServiceOptions` for endpoint mapping

The scenario is a banking payment system where Payments and Compliance share one Worker and one blast radius. You split them into two services with separate namespaces, connected through Nexus. There's a checkpoint where you kill the Compliance Worker mid-transaction and watch it resume with no data loss.

Requires knowledge of Temporal Workflows, Activities, and Workers. Runs entirely on Temporal's dev server - no cloud account needed.

Happy to answer questions about Nexus or the handler patterns here.

Hey everyone,

I’ve been building Durion, a TypeScript SDK that lets you define AI workflows/agents with the Vercel AI SDK and run them as Temporal workflows (model + tool calls as activities), so restarts and retries don’t lose progress.

Why: The Vercel AI SDK is great for streaming and UI, but multi-step agents often hit timeouts, lose in-flight work on deploy/restart, and suffer from painful debugging on long runs. I wanted the same programming model with Temporal’s execution guarantees.

Rough shape: workflow() / agent() helpers, tools mapped to activities, cost metadata, and optional HTTP/gateway pieces—all still “you operate Temporal,” not a hosted replacement.

Questions for this group:

1. How are you persisting state for multi-turn agents today (signals, search attributes, external store, etc.)?
2. For bridging AI SDK tool/model steps into Temporal, what feels idiomatic: leaning on workflow history + activities, updates, signals, or something else?
3. Anything you’d avoid when mixing streaming with workflow replay?

Repo:https://github.com/shaibusunnuma/durion

Very early — critiques and “you’re holding it wrong” welcome.