Official SDKs for six platforms, a native OpenTelemetry receiver, and a plain HTTP API mean almost anything can log to ZipLogger today, and the list keeps growing.
First-class support via the ZipLogger.Client core package: batching, retries,
backpressure, and automatic release/commit enrichment. Full docs →
Two lines in Program.cs. Request logs, scopes, and unhandled exceptions flow
automatically through the standard logging pipeline. Full docs →
.WriteTo.ZipLogger(endpoint, apiKey): structured properties, destructured
objects, and exceptions preserved as searchable fields. Full docs →
builder.Logging.AddZipLogger(...): an ILoggerProvider with scopes,
config-file binding, and per-category level filtering. Full docs →
A dependency-free logging handler: pip install ziplogger, add
ZipLoggerHandler, and extra= values become searchable fields;
tracebacks feed regression detection. Full docs →
npm install ziplogger: a zero-dependency core client plus first-class
Pino and Winston transports with the same batching and retry semantics as
the .NET packages. Full docs →
go get a standard-library-only client with a first-class log/slog
handler: attributes become searchable fields, err attrs feed regression
detection. Full docs →
A JDK-only client (Java 17+) with a java.util.logging handler. Zero dependencies,
same batching and retry semantics as every other SDK. Full docs →
The official sentry-ruby SDK with a ZipLogger DSN: errors and Issues with source
lines, tracing, structured logs, cron check-ins and profiles, and Rack, Rails and Sidekiq report
unhandled errors. Tested with sentry-ruby 7.1.0. Setup →
The official sentry/sentry SDK (or its Laravel and Symfony packages) with a ZipLogger
DSN: errors and Issues with source lines, tracing, structured logs, cron check-ins and profiles.
Tested with sentry/sentry 4.34.0. Setup →
@ziplogger/browser captures uncaught errors and unhandled rejections, flushes
on page unload, and ships a React error boundary with component stacks. Errors with a stack trace are grouped into
Issues; upload source maps to read minified frames. Full docs →
Native OTLP/HTTP receivers for logs, traces and metrics (protobuf or JSON, gzip). Point
OTEL_EXPORTER_OTLP_ENDPOINT at ZipLogger with an ingest key. Spans become request
waterfalls on the Traces page and feed APM: latency, errors and traffic per service and
endpoint, dependencies and an observed service map. Set service.name and
service.version; the ingest key decides the environment.
APM docs → Full docs →
Keep Sentry.init and change the DSN. Errors become log lines and Issues, with
your fingerprint honored; transactions become traces; structured logs and cron
check-ins become log lines, and cron check-ins also report to a matching heartbeat; profiles
become flame graphs. Replays and attachments are not stored, so this is Sentry-compatible
ingestion, not the whole Sentry product. Tested end to end with the official
Python, Node.js,
Go, Java, Ruby,
PHP and .NET SDKs.
How to switch → Full docs →
One curl call per build uploads your JavaScript source maps with a key that can
upload and nothing else. Minified browser frames then read as the original file, line and code
on the Issue page. Maps stay private to your workspace. sentry-cli uploads are not
accepted. Full docs →
Mixpanel-shaped ingestion on /track, /import and
/engage: point an already-instrumented SDK at ZipLogger and your event names,
properties and identity calls keep working. How to
switch → Full docs →
One-click GitHub App connect (or a fine-grained token) powers regression detection: blame the stack trace's files through the GitHub API, no cloning, revocable anytime. Full docs →
gitlab.com or self-managed. Add a project access token with read_repository and
regression blame works exactly as it does on GitHub. Full docs →
From a ZipLogger Issue, create an issue in GitHub (through a repository you already connected), Jira Cloud or Linear, or link one that exists. It carries the title, service, location, counts and releases with a link back, never the error message, stack trace or user data. Status does not sync both ways, Jira Server is not supported, and GitLab issues can be linked but not created. Full docs →
ZipLogger is a Model Context Protocol server, so your AI assistant can search logs, cluster errors, walk traces, and read regressions itself. One command to connect. Full docs →
SMS and voice-call alerts work out of the box with a monthly allowance, or bring your own Twilio account and send at your own Twilio rates. Replying to a paging text with its code acknowledges the incident. Full docs →
Bring your own Collector: add ZipLogger as an otlphttp exporter to send logs,
traces and metrics from any language or agent. You write and run the Collector config. Traces
that pass through it feed APM like any other; if it samples by outcome, APM labels those counts
as observed spans. Full docs →
One helm install per cluster, with a collector key from the Kubernetes Install
page. ZipLogger’s chart runs the upstream OpenTelemetry Collector with read-only access: it
reports nodes, workloads, pods and events, detects failures such as crash loops, image pull errors
and missing Secrets, and can ship container logs and forward your apps’ OTLP. You do not write
a Collector config. Full docs →
One authenticated endpoint accepts a single event, a JSON array, or NDJSON streams. If it can POST JSON, it can log to ZipLogger: cron jobs, shell scripts, legacy apps. Full docs →
Installed Slack and Teams apps, not webhooks: incidents post to the channel you choose, update in
place, and carry Acknowledge / Assign to me / Resolve buttons that act on the real incident as the
person who clicked. The Teams app is not in the Teams store yet: your Teams admin adds it from a
package, and installs outside ZipLogger’s own tenant are not yet verified. Plain webhooks
({"text": "…"} — Discord, Mattermost, your own
automation) remain available on alert rules. Slack docs → ·
Teams docs →
We operate the platform, you connect apps. AWS, Azure, GCP, a VPS, or the machine in your rack: if it can make outbound HTTPS calls, it can log to ZipLogger. Kubernetes monitoring adds one read-only Helm release per cluster, and it too only makes outbound HTTPS calls. Get started →
Logs and metrics are isolated per workspace and encrypted in transit. ZipLogger does not sell them or use them to train models. Export any time, deleted on request. Privacy policy →
The same hosted platform serves a side project and a production fleet logging millions of events a day. Search stays fast, and there is no capacity planning to do. Plans →
Tail files and containers from apps you can't modify; the http output ships
NDJSON straight to ZipLogger. Copy-paste pipeline →
High-performance pipelines with remapping: rename keys, set severities, and stream to the ingestion endpoint. Copy-paste pipeline →
Filebeat, syslog relays, custom scripts: if it can POST newline-delimited JSON with a header, it can feed ZipLogger. Full docs →
Push incidents to a PagerDuty service with an Events API v2 key; acknowledging or resolving on either side updates the other. Setup →
Same, with an Opsgenie API key and your US or EU region. One alert per incident, whatever we retry. Setup →
Paste a channel’s webhook URL. Each incident is one message, a coloured embed with status,
severity, service and a link, edited as it is acknowledged and resolved. Mentions are off, so a
title can never ping @everyone. No buttons. Setup →
A bot token from @BotFather and a chat id or @channel. One message per incident with an
Open in ZipLogger button, edited in place as it changes. ZipLogger checks the bot is in the chat
before saving. No acknowledge button. Setup →
No plugin: point Grafana's own Loki, Prometheus and Tempo data sources at ZipLogger and query your logs, traces, and a fixed catalog of six request metrics — a deliberate subset, not a general Prometheus remote-read endpoint. Setup →
Google Cloud Monitoring, Datadog, Grafana alerting, New Relic, Prometheus Alertmanager (for example from a cluster’s existing Prometheus stack), GitHub Actions, Jenkins, AWS CloudWatch, Azure Monitor and a generic webhook — all become incidents with the same dedupe, escalation and on-call routing. Alert docs →
Deeper links from a Grafana panel straight into the matching ZipLogger incident. Today: alerts from Grafana already open incidents, and dashboards already query ZipLogger. Grafana docs →
A weekly deploy window, set once. Today: windows are single periods, and you can create as many as you need. Alert docs →
Tell us what your stack looks like. Integrations are prioritized by real demand.