Introduction to latency

Early warning and outage alerts for every service.

Today's products run on infrastructure outside the your team's control: CDNs, payments, databases, storage, and managed clouds. When one of those breaks, customers usually notice long before the provider's status page is updated. latency closes that gap.

We've combined real reports and live feeds from around the world into a single pane of glass and give you full visibility into the data for your services and it's dependencies.

Start here

• Quick Start: first site monitored in minutes
• iOS app on the App Store and how the app works
• Platform primitives: the public APIs
• Telemetry: application logs, traces, metrics and events beside monitoring
• What comes next: Roadmap

Notice

Some platform features are in the final stages of beta testing. Pages marked Beta are still a work in progress and subject to change.

Who uses our platform

• Teams shipping services people rely on. First notice of issues, reconciled across every source, on degradation and again on recovery.
• Teams built on third-party services. Stripe or PayPal, a CDN, a database host. Our probes watch those providers alongside owned services, so a provider's bad day never arrives as a surprise.
• The curious. Watch any address on the internet, or inspect any host on the public inspector for the same view our probes have.

Quick questions

How does latency stay up when cloud providers go down?

Our cloud services are not immune to outages. The difference: copies of our platform run in many datacenters as small units called Cells, with no single point of failure, and every service is designed with outages in mind.

Is an account required?

Not for exploring. The public platform primitives (DNS, geo and inspect) need no sign-up. Accounts hold monitors, alerts and incidents.

Is the code open source?

The backend is not open source (yet). Our CLI is, under MIT.

How does this differ from Datadog or Grafana?

Those are large observability suites for instrumenting application code. Our focus is the network and dependency question: is the service reachable, is the service fast, and is the infrastructure underneath having a bad day? Application logs, traces and metrics can sit beside monitoring too: Telemetry accepts any OpenTelemetry SDK.

Ping and traceroute already exist.

Our probes use both. The difference is memory: results are kept, connected across providers, and turned into alerts when something changes.