Mydle documentation
Observe, understand, and act on reliability
Guides for connecting uptime checks, real-user browser signals, logs, traces, and incidents in one workspace — grounded in observed evidence.
Get your first real signal
Create a project and verify your first signal in a few steps.
- Step 1: Create a projectSign in and create a project for the service you want to watch.
- Step 2: Add an HTTP monitorCheck a production URL on a schedule. Results come from real probes.
- Step 3: Install the browser SDKSend real-user sessions, errors, and Web Vitals with @mydle/browser-sdk.
- Step 4: Send structured logsShip server logs with @mydle/logs — 50 MiB / month on Free, 1 GiB on Pro.
Guides by product area
Mydle follows one model: observe signals, understand impact, then act.
Observe
Collect signals from checks, real users, logs, traces, and deploys.
Understand
Connect signals through shared IDs and observed evidence.
Act
Respond with alerts, incidents, notifications, and status pages.
Build
Integrate with the API, SDKs, webhooks, and OpenTelemetry.
What Mydle is#
Mydle connects uptime monitoring, real-user browser signals, structured logs, distributed traces, incidents, and impact views into one workspace-scoped control plane. Every claim in the product is grounded in observed evidence — quiet sources stay quiet.
Positioning stays fixed: Observe → Understand → Act.
Why it exists#
Reliability work fails when tools disagree on tenancy, invent missing data, or bury correlation behind timestamps. Mydle keeps Postgres as the control plane for config and product state, joins telemetry on explicit IDs (trace_id, session_id, request_id), and labels AI output as Observed, Likely, or Unknown — never as autonomous remediations.
How it works#
- Observe — HTTP / SSL / DNS monitors,
@mydle/browser-sdkRUM,@mydle/logsingest, and OTLP traces. - Understand — explorers, correlation, incidents, impact, and evidence-driven AI insights when entitled.
- Act — alerts, notifications, status pages, and human-owned incident lifecycle.
Storage: PostgreSQL is the control plane and the source of truth for logs and browser RUM. ClickHouse is an optional secondary store for tracing (dual-write after Postgres persist; fail-open). Without ClickHouse configured, tracing continues on Postgres alone.
Product surfaces#
- Monitoring — HTTP with daily SSL / DNS checks
- Browser monitoring — RUM via
@mydle/browser-sdk - Logs — structured ingest via
@mydle/logs - Tracing — OTLP ingest and explorer
- Correlation, incidents, impact, AI insights
Plans snapshot#
One package per workspace, priced per workspace — not per user. New subscriptions are monthly. Nothing bills automatically for overage; Pro workspaces can add monthly capacity add-ons.
| Limit | Free | Pro |
|---|---|---|
| Price | $0 / workspace / month | $19 / workspace / month |
| Active HTTP monitors | 3 | 10 |
| Fastest check interval | 10 min | 5 min |
| SSL & DNS checks | Daily | Daily |
| Detailed check history | 1 day | 7 days |
| Daily uptime summaries | 7 days | 90 days |
| Log ingestion | 50 MiB / month | 1 GiB / month |
| Browser events | 5,000 / month | 50,000 / month |
| Trace spans | 50,000 / month | 1,000,000 / month |
| AI analyses | 2 / month | 20 / month |
| Log, browser & trace retention | 1 day | 7 days |
| Outage & recovery email | Included | Included |
| Capacity add-ons | Upgrade to Pro | Available |
Full gate tables: Limits & Quotas.
Limitations
- Docs describe shipped behavior only. Roadmap catalog monitors (store listings, Firebase, etc.) are not activatable.
- Continuous monitor scheduling needs production Trigger workers; local-only setups will not invent check results.
- ClickHouse is optional for tracing. Logs and browser data remain on Postgres.