Sources

Connect your security logs and events from cloud providers, SaaS applications, and infrastructure to RunReveal's security data platform. Search by name or description, and filter by ingest method, category, or plan.

---

Ingest Methods

RunReveal sources provide a few different ingestion methods for sending us data. Some sources may provide more than one option when setting it up.

Webhook

A webhook source will generate a unique URL that can be used to forward events to. This URL is provided to your app and events are sent to RunReveal and processed.

Webhook sources can be the easiest to setup and maintain but are the most prone to errors. Networking issues that may cause HTTP requests to fail can mean events are lost. If given an option, setting up retries for events can give some error handling in these scenarios. Every source is different and retries are not guaranteed to be available.

Polling

A polling source is the most common ingestion method that RunReveal offers. Polling sources work by making an API call to the source and returning events that have occurred. These API calls are usually performed on a 60 second timer, RunReveal stores a token indicating where we left off and requests all new events (some sources may only request a limited amount to reduce the number of events returned).

Every polling source is different, but generally RunReveal requires some sort of account identifier and some sort of access credentials to view your logs. These access credentials are stored in RunReveal, in an encrypted format, and used to authenticate to the source on your behalf. If an error occurs such as a network outage or the source is down, RunReveal will be able to pick up where we left off to make sure no logs are missed.

Object Storage

RunReveal offers a few different object storage providers and methods to ingest logs. However, these ingestion types all work in a similar manner allowing you to keep a backup of your log events in a storage bucket that you control. Sources providing these can range from cloud provider logs, SAAS applications that store logs in a bucket, or event generic buckets that store custom logs.

Below you will find links to help setup and explain each of the object storage providers that we support.

These ingestion types work by:

1. Storing an object containing a number of events in a blob storage container.
2. Sending an object creation notification to a message queue.
3. RunReveal will subscribe to this queue and read new notifications.
4. RunReveal will download the object listed in the notification.
5. RunReveal will read, process, and ingest the events in the blob object.

AWS S3 Bucket

Logs are stored in an AWS S3 bucket that is under your control, object creation notifications are forwarded to one of RunReveal's SNS topics. Once we receive the notification we will download the object and begin processing events. Setup guide →

AWS S3 Bucket with Custom SQS

Similar to the regular S3 method, events are stored in a bucket that you control. Object notifications are instead sent to an SQS queue that is also in your control. RunReveal will subscribe to your SQS queue and process the notifications. Setup guide →

Azure Blob Storage

Logs are stored in a storage account container in your Azure subscription. Object creation notifications are sent to a storage queue where RunReveal will subscribe and process the notifications. Setup guide →

Google Cloud Storage Bucket

Logs are stored in a GCS bucket in your GCP account. Object creation notifications are sent to a pub/sub topic and RunReveal will subscribe to the topic to process the notifications. Setup guide →

Cloudflare R2 Bucket

Logs are stored in an R2 bucket in your Cloudflare account. Object creation notifications are sent to a Cloudflare Workers Queue and RunReveal will read from event notifications from the queue and process the objects that have been created. Setup guide →

Transform

Along with the standard setup for the source, you can also select an existing transform that was created to help normalize your fields.

Leaving this field blank will use the standard transform for this source. Custom sources (e.g. webhooks or object storage) will not have any transformation applied.

Health Checks

RunReveal offers the ability to enable health checks on your sources to monitor log ingestion and alert you when sources stop sending data. Health checks help you detect data gaps early and maintain continuous security visibility.

Learn more about configuring health checks →

FAQ

How do I enable a source?

On this page, use the filters at the top (ingest method, category, plan) and sort by name or release date to find an integration. If you are unsure, start with the vendor’s name (e.g. Okta, CloudTrail).

In the RunReveal app, open Sources, then choose Connect a new source. The catalog appears as a grid of tiles—use the search box on that page if you need to find a specific integration. Click Connect on a tile to open the setup flow for that source type; complete credentials and settings, then save to enable the source. If there is no official integration, use Custom Source or Generic when you can deliver via webhook or supported object storage.

If your source requires API polling, reach out to RunReveal support to submit a source request. Please provide any API documentation links and exported logs we can use for normalizing fields.

How do I start collecting logs?

Create a source in RunReveal for each system or pipeline you want data from (one source per vendor or integration is typical). Choose an ingest method that matches how your logs leave the upstream system—webhook if something can POST to a URL, polling if we pull from an API on a schedule, or object storage if batches land in a bucket. After setup, use health checks to confirm events are arriving.

Should I use Custom Source or Generic sources?

Use Custom Source or Generic when RunReveal does not yet provide an official source integration for that product, but you can deliver logs in a standard way we support.

If the data can be collected via webhook, Amazon S3, Google Cloud Storage, Azure Blob Storage, Cloudflare R2, or MinIO, we suggest starting with Custom Source (guided wizard and optional field mapping) or Generic (bucket notifications into the generic pipeline—see the Generic page for SNS topic and setup details).

If your source requires API polling, reach out to RunReveal support to submit a source request. Please provide any API documentation links and exported logs we can use for normalizing fields.

How can I collect syslog or local custom logs and normalize the data?

There is no separate “syslog” source in the catalog. Point syslog at a forwarder that can turn events into JSON and send them to RunReveal—for example Fluent Bit or reveald listening for syslog—then target your Custom Source or Structured Webhooks URL. For local files, host metrics, or mixed workloads on the machine, reveald can tail files, journald, windows, and other reveald source types and forward to your webhook.

To normalize arbitrary JSON into RunReveal fields, use the Custom Source wizard (full guide):

1. Choose ingest method — Webhook, AWS S3 (including Custom SQS), GCS, Azure Blob, R2, or MinIO.
2. Configure connection — Name the source, enter credentials or paths, then Verify Settings so RunReveal can sample data.
3. Preview data — Confirm the JSON shape from your preview batch.
4. Field mapping (optional) — Map JSON paths to normalized columns (or use suggestions); this drives transforms for consistent querying.

How do I collect Windows host or Event Log data?

For an agent-based path on Windows (and other OSes), use reveald with the windows source type in reveald’s config, pointed at your RunReveal webhook. For details on supported source and destination types, see reveald documentation.

Can I send OpenTelemetry data?

Yes. Use the OpenTelemetry (OTLP JSON) source when you have OTLP-compatible JSON logs (for example from an SDK or collector) delivered over supported ingestion paths. For forwarder-oriented setup, see OTLP JSON (forwarder).