Proactive Monitoring for Okta Workflows using Datadog

Your Okta Workflows will fail. Maybe not today — but eventually, they will.

The last thing you want during a long weekend is waking up at 3 AM to a flood of alerts from your ITSM tool, each one representing an incident your team now has to scramble to resolve. And finding out about a broken workflow because a customer complained? That's a situation you never want to be in.

Proactive monitoring exists precisely to prevent this. The goal is simple: know about the problem before it becomes your problem — and fix it before it ever impacts your business.

TL;DR

If reading is not your thing, I also walked through this entire setup in a webinar as part of an Okta Workflows Community Meetup — it might be a helpful complement to this article.

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

Introduction

In August 2025, Okta introduced Execution Log Streaming, a native feature designed to deepen integration with your existing observability stack and give you real-time visibility into your workflows' health.

In this article, you'll learn:

What Execution Log Streaming can do for you
How to integrate it with Datadog
How to build Monitors and Notification Rules in Datadog
How to send additional debug information directly from your flows

What is Execution Log Streaming?

This feature allows real-time streaming of workflow executions to external observability tools (SIEM), without requiring additional configuration or helper flows. No more in-product only visibility, from now on you will be able to quickly identify issues and fix them before they become into majors.

Benefits

Keep execution metadata beyond 30 days — your execution history lives in your SIEM for as long as you need it, making audits and compliance reviews significantly easier.
Get alerted before your users do — configure real-time alerts for flow failures and catch issues before they turn into incidents
Full visibility into recurring problems — spot patterns in errors and performance bottlenecks that would otherwise go unnoticed
Works with the tools you already use — plug directly into Splunk, Datadog, Sumo Logic, Panther, or any SIEM of your choice.
No extra flows, no extra costs — unlike helper flow workarounds, this is a native feature that doesn't count against your Workflows quota.
Self-service and low maintenance — define your destination, pick your event types, and you're done; no ongoing configuration overhead.
Granular control — monitor every single flow or focus only on the ones that are business-critical or high-risk.
No storage limits or platform dependencies — your data, your infrastructure, your rules.

Instead of using helper flows to stream information to a SIEM, the Execution Log Streaming is a built-in feature. This minimizes the amount of configuration and maintenance required. Also, unlike using helper flows, Execution Log Streaming doesn't count against the number of flows included under your Okta Workflows limits.

How to configure it?

Prerequisites

Datadog Account with an API Key generated
Okta Tenant with Okta Workflows enabled
Super Administrator Role (just during the configuration changes)

Execution Log Streaming settings

To configure the integration you need to follow these steps:

Go to your Okta Workflows Console
Click on Settings
Select the Execution Log Streaming tab
Click the Edit button
Enable the toggle button Enable execution log streaming

Now enter the information described below:

URL - You will need to get this URL from the documentation depending on the region where your Datadog Account belongs to. You can get yours from this URL.
- https://http-intake.logs.datadoghq.eu/api/v2/logs
Authorization Headers - Remember not to include this header in the Optional Headers as it is not a secure way of information exchange.
- DD-API-KEY: [YOUR_DATADOG_API_KEY]
Flow settings - This checkbox will determine if newly created flows will be automatically sending its metadata to the monitoring solution. In most of the cases I recommend to enable it so you are just manually enabling the monitoring for flows that are enoughly prepared for production, that way you can reduce unneeded alerts and noise from the Operation Teams.
Other Custom Headers (Optional) - This set of headers is recommended by Datadog for the HTTP API Endpoint to properly understand the information exchange.
- Accept: application/json
- Content-Type: application/json

Custom event body - JSON payload for Datadog structure

{
    "ddtags": "env:production,service:okta",
    "ddsource": "okta-workflows-els",
    "hostname": "[YOUR_OKTA_WORKFLOWS_TENANT].workflows.okta.com",
    "message": "${event}",
    "service": "okta"
}

Feel free to include as many ddtags as you want depending on your needs.

Make sure to adapt the existing values as all of them except by event can be replaced by any other value.

Once you have entered all the needed information, click on the Save button. and then click on the Send test event button available at the top of the configuration page.

This will allow you to validate if the communication is correctly happening. If everything went well you should see something like this:

Configure individual log monitoring

Based on your needs and the value that the flows can add in your observability strategy, you can decide to enable just a few critical flows and disable some other low impact flows that could be generating noise and extra storage needs on your monitoring solution without being really useful.

For you to configure indivial flow monitoring follow these steps:

Open the Okta Workflows Console.
Open the Flows Tab, and identify the target flow.
Open the target flow and click the dropdown menu for the flow status.
Change the toggle beside the Stream execution logs for this flow to enable or disable the log streaming option for this particular flow.

How to process the incoming logs in Datadog

Datadog does a good job of automatically recognizing standard attribute names and mapping them to its reserved attributes — but Okta Workflows doesn't always speak the same language. Some of the attributes coming from Execution Log Streaming are non-standard, which means Datadog won't know what to do with them out of the box.

To fix that, you'll use Pipelines — a Datadog feature that lets you intercept incoming logs and reshape them into a structure that works better for querying, alerting, and building dashboards.

Flow metadata

This is the base metadata structure included in every execution event once the integration is complete. In Datadog, any attribute can be used to filter your logs - so plan your strategy carefully to get the most out of your incoming events.

{
  "event_type": "FLOW_START",
  "execution_id": "4632dc20-6989-4c57-9b5f-c17528474086",
  "timestamp": "2024-04-04T18:30:38.730Z",
  "flow_id": "01J29TGKQERR78AD3VN0P9DPSW",
  "flow_name": "Log Stream Example",
  "org_id": "01J29TH3XHECT79M257GG2QTKJ",
  "org_name": "logstream-01",
  "org_hostname": "atko.okta.com",
  "user_id": "01J29TRZDZKSY6V70GATDAHN2N",
  "user_email": "jessie.doe@example.corp",
  "parent_execution_id": "5001fcad-2ec4-4cd8-935e-57f14166e673",
  "parent_flow_id": "01J29TTH757HFCK5FPMCRCT6A3",
  "parent_flow_name": "Immediate Parent Flow Calling Example Flow",
  "root_execution_id": "0af35fac-d6d8-47cc-b59a-9954711c5ec8",
  "root_flow_id": "01J29TTS7X37QSTKPJBGS52ENF",
  "root_flow_name": "Root Flow Calling Example Flow",
  "folder_id_path": "01J2CT7B5P5DFHKFDE85FW6BTV/01J2CT9EN0Q26F3BX8YMWE1EDX",
  "folder_id": "01J29T9NX4WVFNNSDG2FMQBYR8",
  "folder_name": ["My parent folder", "My child folder"],
  "engine_mode": "realtime",
  "idempotency_key": "f1aaa750-6d92-485e-acf7-dd167e00db2f",
  "throttled": "false"
}

Pipelines

Not all attributes coming from Okta Workflows will be automatically recognized by Datadog — some will need a bit of transformation before they become truly useful. That is where log pipelines come in.

A pipeline takes your raw incoming logs and transforms them into a clean, consistent format that Datadog can work with. Beyond just parsing, pipelines are also a great opportunity to enforce a naming convention across your organization, making it easier to build dashboards, alerts, and queries that are consistent and maintainable over time.

To generate a new pipeline follow the next steps:

Log in to your Datadog account and navigate to Logs → Pipelines.
Click on the + New Pipeline button.
Set the filter using the following query:
- service:okta source:okta-workflows-els
Enter a name for your pipeline (e.g., Okta Workflows Execution Logs)
Click the Create button to save the pipeline.

Processors

These processors need to be included in the pipeline so the log can be correctly transformed and used in the Datadog Monitors and Notifications.

Inside the pipeline, click the Add Processor button to start defining the following processors:

Lookup processor - Define some transformation from the source event_type attribute to the target status attribute. This snippet of code can be used, but you can customize it according to your needs:
```
FLOW_FAIL, error
FLOW_THROTTLE, warning
FLOW_CANCEL, notice
```
Normally you should use info as fallback, so any other event_type can be considered as such. Use event_type as the source and status as the target attribute.
Status remapper - Add a status remapper using status as attribute.
Error kind remapper - Add a remapper with error_type as the source and error.kind as the target attribute.
Error message remapper - Add a remapper with error_message as the source and error.message as the target attribute.
Trace Id remapper - Add a trace id remapper using root_execution_id, execution_id as attributes.

Managing alerts

Monitors

Monitors are Datadog's alerting engine. They continuously evaluate your logs, metrics, or events against conditions you define, and trigger a notification when something looks off. In the context of Okta Workflows, you can use them to get alerted the moment a flow fails, starts throwing repeated errors, or behaves in a way that could indicate a deeper issue.

Creating a Monitor in Datadog

Navigate to Monitors → New Monitor.
Select the monitor type — for log-based alerting, choose Log Monitor.
Define the search query to filter the logs you want to monitor, in this case we use the following one:
- service:okta source:okta-workflows-els env:production status:(warning OR error).
Set the evaluation criteria — what condition should trigger the alert (e.g., number of events exceeds a threshold).
Configure the alert threshold and the warning threshold to values consistent with your monitoring needs and maturity landscape.
Set the evaluation window — the time period Datadog uses to evaluate the condition
Add a monitor name and a description (optional).
Configure the notification message — what gets sent when the alert fires, Datadog offers many variables that can be included in the email template so you can make it even more informative.
Set the notification channels — you can do this directly on the Monitor using channels such as email, Slack, PagerDuty, etc. But the best practice is to use Notifications Rules so Datadog can automatically map them based on your Monitor Tags.
Define tags for the monitor to make it easier to manage, filter, and automatically link it to the notification rules.
Click the Create button to save the monitor.

Notification Rules

Notification Rules give you control over who gets notified and how. Instead of hardcoding notification channels inside each individual monitor, you can define rules at a higher level — routing alerts to the right team, Slack channel, or on-call rotation based on tags, severity, or monitor type. This makes your alerting setup much easier to maintain as the number of monitors grows.

Creating a Notification Rule in Datadog

Navigate to Monitors → Settings → Notification Rules.
Click on the + New Rule button.
Define the filter criteria — which monitors this rule applies to, based on tags, severity, or monitor name. In this case we use the following one:
- service:okta source:okta-workflows-els.
Set the notification channels — Slack, PagerDuty, email, webhook, etc.
Configure the escalation settings if needed — e.g., re-notify if the alert is not resolved after X minutes
Add a rule name for easy identification
Click the Save button to activate the rule

Events

Execution Log Streaming

There could be cases where you do not want to send all the event types to your monitoring solution, configure just the needed ones to avoid the extra noise and storage needs.

Starting flows
Successfully completed flows
Flows that failed due to errors
Flows canceled by users
Paused flows
Flows that are rate limited by third-party services
Flows throttled by Okta

Okta System Log

When the Execution Log Streaming settings are changed either at organization or flow level, there will be especific events being raised that you can monitor.

Organization

workflows.user.execution_log_stream_connection.activate
workflows.user.execution_log_stream_connection.deactivate
workflows.user.execution_log_stream_connection.update

Flow

workflows.user.flow.execution_log_stream.activate
workflows.user.flow.execution_log_stream.deactivate

Limits

Datadog

Maximum content size per payload (uncompressed): 5 MB.
Maximum size for a single log: 1 MB but recommended that an individual log be no greater than 25 K bytes.
Maximum array size if sending multiple logs in an array: 1000 entries.
A log event should not have more than 100 tags, and each tag should not exceed 256 characters for a maximum of 10 million unique tags per day.
A log event converted to JSON format should contain less than 256 attributes. Each of those attribute’s keys should be less than 50 characters, nested in less than 20 successive levels, and their respective value should be less than 1024 characters if promoted as a facet.
Log events can be submitted with a timestamp that is up to 18 hours in the past, otherwise they will be omitted.

Okta

Depending on your commercial agreement with Okta, there will be different limits on the number of events that you can send to your monitoring solution, so check them in advance and choose the flows to be monitored according to this limit and its monitoring value.

Proactive Monitoring for Okta Workflows using Datadog

Introduction