DEV Community: Sara

Your System Can't Tell You It's Down: Why Synthetic Monitoring Matters

Sara — Thu, 06 Aug 2026 15:52:52 +0000

Synthetic monitoring detects availability problems before users do by running automated checks against your applications from outside the system. Unlike logs, metrics, and traces, synthetic checks can detect failures even when your application is not receiving traffic.

Your observability stack tells you what happened inside your system.

But what happens when the system itself is unavailable?

A broken TLS certificate, expired domain, failed API endpoint, or broken checkout flow may produce little or no telemetry because requests never reach your application.

That is the gap synthetic monitoring solves.

What is synthetic monitoring?

Synthetic monitoring uses automated probes to continuously test applications, APIs, and user workflows.

Common examples:

Checking an API endpoint returns the expected response
Verifying TLS certificates before expiration
Testing TCP connectivity
Running a complete browser workflow like login or checkout

Instead of waiting for customers to report problems, teams detect failures proactively.

Synthetic monitoring without another tool

Many synthetic monitoring solutions create another observability silo.

You end up with one dashboard for logs, another for metrics, another for traces, and another for synthetic checks.

OpenObserve Synthetic Monitoring keeps check results alongside your existing telemetry.

Synthetic results can be queried, added to dashboards, and used for alerts alongside logs, metrics, and traces.

Test APIs and real user journeys

OpenObserve supports:

HTTP checks
TCP checks
TLS checks
SSH checks

For browser monitoring, checks run using Playwright.

Engineers can use existing Playwright scripts or record browser journeys and convert them into monitors.

The same workflows used for testing can also help detect production issues.

Monitor internal applications

Public synthetic checks cannot always reach internal systems.

Private Locations allow teams to run synthetic checks inside their own network using an outbound-only agent.

No inbound firewall rules.
No exposing internal endpoints.
No separate monitoring infrastructure.

Know why something failed

A failed check should provide more than "availability dropped."

Each run includes execution history and failure evidence so engineers can understand:

Which step failed
Where it failed
What the application returned
Screenshots of browser failures

Instead of only knowing that something broke, teams can quickly understand what happened.

Getting started

Synthetic Monitoring is available in beta on OpenObserve Cloud.

Create a check, choose your schedule and location, and start receiving results in the synthetics_results stream.

Learn more about Synthetic Monitoring at OpenObserve

What's New: Terraform Support, Kubernetes and AWS Automation, Bring Your Own Bucket, and UX Improvements

Sara — Tue, 19 May 2026 15:23:19 +0000

What's New in OpenObserve: Terraform Support, Kubernetes and AWS Automation, Bring Your Own Bucket, and UX Improvements

OpenObserve has shipped three major updates that help engineering teams automate observability, keep full control over telemetry data, and troubleshoot incidents faster.

In this release:

Terraform support for managing OpenObserve deployments and resources as code
Bring Your Own Bucket (BYOB) for Amazon S3 and Azure Blob Storage
UX and UI improvements for logs, distributed tracing, and root cause analysis

If you run observability on Kubernetes, AWS, Azure, or other cloud environments, these updates simplify deployment, improve governance, and streamline day-to-day troubleshooting.

Terraform Support for Observability as Code

OpenObserve now includes a Terraform provider that lets you manage observability resources using infrastructure as code.

Supported resources include:

Streams
Dashboards
Users and organizations
Retention policies
Indexed fields
Full-text search settings

OpenObserve also provides a Kubernetes Terraform module that deploys the platform using the official Helm chart. The module supports both single-node environments and production high-availability deployments with PostgreSQL, NATS, S3, and Ingress.

For AWS users, the module can optionally provision:

Amazon VPC
Amazon EKS
Amazon S3
IAM roles

This makes it possible to manage both the observability platform and its configuration through Terraform or OpenTofu.

Bring Your Own Bucket (BYOB) for Amazon S3 and Azure Blob Storage

Commercial OpenObserve Cloud customers can now connect their own Amazon S3 bucket or Azure Blob Storage container.

Telemetry data remains in your cloud account, region, and security boundary, while OpenObserve continues to handle ingestion, compaction, and querying.

Key benefits include:

Full ownership of logs, metrics, and traces
Data residency and compliance control
Better use of existing cloud storage commitments
No storage lock-in

UX and UI Improvements for Logs and Distributed Tracing

This release also includes several improvements to help engineers move from alert to root cause more quickly.

Highlights include:

Service Catalog
Span details directly in the flame graph
Better default log columns
Multi-stream log correlation
Smarter View Logs filters

These changes reduce the number of clicks required to investigate incidents and correlate logs and traces. Try it!

Get all the details, features, and how-tos:

This article is a summary of the latest OpenObserve release.

For screenshots, implementation details, and links to the Terraform provider and Kubernetes module, read the full announcement.

OpenObserve Just Raised $10M and Launched Observability 3.0 with New AI Capabilities

Sara — Wed, 29 Apr 2026 14:16:01 +0000

Today we’re announcing two things:

A $10M Series A
The launch of Observability 3.0

This funding accelerates a shift we’ve been building toward: Observability 3.0.

Observability is breaking under AI-scale systems.
More data. More tools. More noise.

Most teams are still:

1. Stitching together 6 – 15 tools
2. Sampling away critical data
3. Debugging incidents manually

That model doesn’t scale.

So we built something different.

Observability 3.0 is a shift from dashboards and alerts to systems that:

Correlate data automatically
Detect issues early
Help resolve incidents without manual digging

This includes:

AI SRE (autonomous incident analysis)
Anomaly detection (early warning signals)
LLM observability (visibility into AI systems)

All in a single platform. No fragmentation. No forced tradeoffs.

This is what the Series A is fueling.

👉 Full story, vision, and what we’re building next: https://na2.hubs.ly/H059Cq20