Octeth v5.8.3 Now Available! See What's New

Octeth v5.8.3: Smarter Journeys, Better Monitoring, and 55 Fewer Bugs

Octeth v5.8.3 ships 81 commits over 15 days: automatic recovery for stuck journey entries, a new ScheduledPull trigger, the Log Observer and System Health dashboard, revenue attribution with duplicate conversion prevention, and 55 bug fixes that address real operational pain points.

Octeth Team

Email Marketing Experts

9 min read
Octeth v5.8.3: Smarter Journeys, Better Monitoring, and 55 Fewer Bugs

Octeth v5.8.3: Smarter Journeys, Better Monitoring, and 55 Fewer Bugs

We shipped Octeth v5.8.3 today. Eighty-one commits across 15 days of development -- 15 new features, 9 enhancements, and 55 bug fixes.

When I planned this release, the direction was clear: make Octeth more reliable, more observable, and harder to break. That shaped every decision. Some of it is visible -- new dashboards, new triggers, new APIs. A lot of it is invisible infrastructure that makes the platform behave correctly in situations where it previously wouldn't. Let me walk through what changed.

Journeys That Recover Themselves

This is the most operationally significant change in the release.

Here's the problem: when a journey worker process terminates unexpectedly -- a crash, a container restart, a deployment -- any entries it was actively processing get permanently stuck. They sit in a "processing" state indefinitely. Never completing, never failing cleanly, just frozen. The only way out was manual intervention, and you had to notice the problem first.

That's now fixed. Octeth automatically detects these orphaned entries and recovers them, re-queuing them for processing without requiring manual cleanup. We've also added a max age guard that prevents entries from ever aging past a configurable threshold without resolution -- a second layer of protection against edge cases that could still slip through.

If you run Octeth in a containerized environment or on infrastructure where workers occasionally restart, this change alone is worth the upgrade. I've seen stuck entries cause real confusion for operators who couldn't figure out why a journey was "running" but subscribers weren't progressing. That scenario is now handled automatically.

The ScheduledPull Trigger

The Journey Builder gains a new trigger type in this release: ScheduledPull.

Unlike event-based triggers that wait for something to happen, ScheduledPull actively pulls subscribers into a journey on a configurable schedule. You define the frequency, it fetches qualifying subscribers and starts them through the flow.

This opens up use cases that event triggers simply can't address. Recurring re-engagement flows. Periodic list hygiene sequences. Weekly digest journeys. Any automation that needs to run against a subscriber set on a cadence rather than in response to a specific subscriber action.

We've included a frequency cap index optimization to keep performance predictable as these scheduled pulls scale. If you're pulling thousands of subscribers into a journey on a daily schedule, the underlying queries need to stay fast. They will.

Log Observer and System Health Check

This release adds proper observability tools to the admin area, and I'm genuinely excited about these.

Log Observer gives you real-time visibility into system logs directly from the Octeth admin interface. No more SSH sessions to tail log files during an incident. No more asking your sysadmin to check what happened at 3 AM. Logs are right there, searchable, and accessible to anyone with admin access.

System Health Check gives you a dashboard-style overview of your Octeth installation's health -- services, workers, key subsystem status -- all in one place. Think of it as a pre-flight checklist for your email infrastructure.

Together, these pair with the LazyOcteth terminal dashboard we shipped in v5.8.2, but they're browser-based and accessible to admins who aren't comfortable in a terminal or don't have SSH access. I've been thinking about the operator experience for a long time. Self-hosted software should give you real tools for real operations work -- not just an admin UI built for end users. These tools are a step in that direction.

The difference between finding a problem in five minutes versus an hour is the difference between a minor incident and an angry customer. Observability isn't glamorous, but it matters.

Journey Queue Monitoring APIs

For teams running Octeth programmatically or building operational tooling around it, this release adds a set of journey queue monitoring APIs.

The new endpoints give you:

  • Queue status -- current state of the journey processing queue, including depth and processing rate
  • Action audit -- history of what actions have been executed and when
  • Email search in queue -- find a specific subscriber's pending journey emails
  • Pending API and CLI command -- query and manage pending journey entries via API or the new journey:pending CLI command

These are particularly useful if you're building monitoring dashboards, integrating Octeth into an ops workflow, or you just want programmatic visibility into what your journeys are actually doing at any given moment. The CLI command is handy for quick checks during incident response without needing to hit the API.

Revenue Attribution and Duplicate Conversion Prevention

This release adds revenue attribution tracking with a critical safeguard: duplicate conversion prevention.

The attribution side is straightforward. You can now tie revenue from subscriber actions back to specific journeys and campaigns. If a subscriber clicks a link in a campaign email and makes a purchase, that conversion is tracked and credited to the campaign that drove it.

The duplicate conversion prevention is the part that matters in practice. Without it, a subscriber who clicks the same link twice -- or triggers the same conversion event through multiple channels -- inflates your numbers. We now deduplicate those. The conversion numbers you see reflect actual, unique conversions.

For anyone running e-commerce or lead-gen campaigns through Octeth, this has been a missing piece. You need accurate numbers to make good decisions about which campaigns and journeys are actually driving revenue. Inflated conversions lead to bad decisions.

Email Gateway Retry Mechanism

The email gateway now has automatic retry logic for transient delivery failures.

Not every send failure is permanent. Temporary connectivity issues, rate limits, brief service interruptions -- these are real and they happen in production. Previously, a transient failure would just fail. Now, the gateway retries intelligently before marking a delivery as failed.

This should meaningfully improve delivery rates for installations where the sending environment occasionally experiences the kind of short-lived issues that are completely normal in production infrastructure. The retry logic is conservative -- it won't hammer a failing endpoint -- but it will recover from the kind of blips that shouldn't cause permanent failures.

Multi-List Subscriber Export

You can now export subscribers across multiple lists in a single operation.

Previously, exporting meant running separate exports per list and merging the results yourself. This is one of those features where the value is immediately obvious to anyone who's hit the limitation. Pick multiple lists, export once, get one file. Simple, but it saves real time for teams managing large subscriber bases across multiple lists.

Timezone-Aware Date Display

All dates in the user area now display in the user's configured timezone.

This sounds like a small change. For global teams, it's been a genuine source of confusion. Campaign send times, subscriber activity timestamps, scheduled dates -- all displaying in server time regardless of where the user actually is. If your server is in UTC and you're in Istanbul, every time you look at "when did this campaign send?" you're doing mental math. That's now fixed. Configure your timezone, and the dates you see reflect it.

MySQL Connection Management CLI

Two new CLI commands for database operations:

  • mysql:set-max-connections -- configure the maximum number of MySQL connections
  • mysql:connections -- view current connection status and usage

These are useful for tuning Octeth's database layer, especially in high-volume environments where connection management directly affects throughput and stability. Having CLI access to these settings means you can adjust them during an incident without navigating through configuration files.

55 Bug Fixes: The Ones Worth Knowing About

Fifty-five bug fixes is a lot. Most are targeted and specific. Here are the ones worth calling out:

Link tracking now only processes http/https URLs -- Previously, link tracking would attempt to wrap any URL, including tel: and sms: links. That broke phone number and SMS links in emails. If you had a "Call us" link in your template, tracking was mangling it into something unusable. Now tracking only applies to web URLs. Phone and SMS links pass through unchanged.

Double opt-in respected during CSV and ESP imports -- Importing subscribers via CSV or ESP migration was bypassing double opt-in requirements. That's a compliance issue, and it's fixed. Imports now respect the double opt-in settings you've configured for each list.

Subscriber.update API rejects unknown custom field IDs -- The API was silently ignoring updates to custom field IDs that don't exist. It now returns a proper error. Silent failures in API operations cause subtle data integrity problems that are hard to debug later. Failing loudly is the correct behavior.

Redis spool orphaned file prevention -- A condition that could leave orphaned files in the Redis spool has been resolved. These orphaned files weren't causing immediate problems but would accumulate over time and consume disk space unnecessarily.

HAProxy ACME routing fixed for SSL renewals -- Custom domain SSL certificate provisioning through HAProxy was failing in certain configurations. If you use custom sending domains with SSL, this fix ensures your certificate renewals work correctly.

Upgrading to v5.8.3

The upgrade process follows the standard Octeth procedure:

  1. Back up your database -- Always. Every time.
  2. Pull the latest Docker images -- Get the v5.8.3 containers
  3. Run the database migrator -- php dbmigrator.php migrate
  4. Restart services -- Bring up the new containers

No breaking changes. The database migration handles schema updates automatically.

What This Release Adds Up To

v5.8.3 is the most substantial reliability release we've done in the 5.8.x cycle. The journey recovery alone addresses something that has caused real operational problems for installations running at scale. The observability additions -- Log Observer, Health Dashboard, Queue Monitoring APIs -- give operators the visibility they need to run the platform confidently. Revenue attribution fills a gap that's been requested for a long time. And 55 bug fixes across a focused 15-day sprint reflects a deliberate effort to close out issues that had been accumulating.

Eighty-one commits. Fifteen days. The platform is in a meaningfully better state today than it was two weeks ago.

If you're an existing Octeth client, login to the Octeth Client Area to download v5.8.3.

If you're evaluating Octeth or want to learn more about what it can do for your organization, fill in our contact form and we'll be in touch.

Octeth is a self-hosted email marketing platform built for businesses and agencies that need full control over their email infrastructure. Learn more at octeth.com.

Share this article