Detect issues, investigate the evidence, page the right person, escalate automatically and resolve — without leaving your observability platform. The incident and the logs behind it are the same system, so the responder starts with the answer in front of them.
On-call rotations · Multi-step escalation · SMS and voice paging · No separate paging tool to buy
Most teams own this workflow twice: a monitoring stack that notices, and a paging product that phones someone. The handover between them is a title and a link, which is exactly the moment the investigation has to start somewhere else. ZipLogger runs all four stages on the same data.
An alert rule over your logs, product events, service health, latency or traffic opens an incident. So does a failed health check, a failing browser journey, a Kubernetes problem detected in a monitored cluster, or an alert forwarded from a monitoring tool you already run. Duplicate alerts fold into the incident that is already open rather than paging twice, flood control caps how many incidents a workspace can raise in a minute, and a maintenance window suppresses paging for planned work.
The incident opens onto the evidence, because the evidence is already here. ZipLogger compares the incident’s window against the equally long window just before it: log volume and error counts, how many lines matched the rule’s own query, request throughput and 95th-percentile latency, and which synthetic runs failed and in which regions. From there it is one step to the error pattern, the trace and the release.
The on-call schedule names the responder and pages them. Escalation steps are ordered, each carries its own delay, and each targets an on-call team or a named person, so an incident nobody has picked up moves along on its own instead of waiting for someone to notice. Acknowledging stops the escalation and records who did it.
A state machine decides which moves are legal, so two people acting at the same moment cannot half-resolve an incident between them. The timeline keeps what fired, every notification attempt and its outcome, who was paged, who acknowledged, what was said and when it closed — which is the record a post-mortem actually needs.
On-call teams have members and roles. A schedule rotates through its participants on a shift length you choose — hours, days or weeks — counted from a rotation start, and the team page shows who is on call right now and who is up next.
Every schedule carries its own IANA time zone, so a rota that hands over at 09:00 local keeps handing over at 09:00 local through a daylight saving change rather than drifting an hour.
Schedule Platform primary Europe/Warsaw
On call now Tomasz Wrona until Mon 09:00
Up next Priya Nair
Rotation 1 week · from 2026-09-01
Override active
Instead of Priya Nair
On call Maya Liu
Until Fri 18:00
Reason conference travel
An escalation policy is an ordered list of steps. Each step has its own delay and targets either an on-call team or a named person, so the second attempt can reach a different rota than the first, and the third can reach a lead directly.
A dedicated background worker drives it. It holds no state between ticks: each pass asks the database for the incidents whose next escalation time has passed and hands them on, and the move itself is a conditional update. That is what stops two API instances — or an escalation racing an acknowledgement — from double-paging the next step.
Per-severity notification policies decide which channels fire for a critical versus a low, and how long to wait between them. Channels are email, SMS and voice call.
Escalation policy Payments · critical
1 immediately on-call team Payments primary
2 after 5 min on-call team Payments secondary
3 after 15 min person Maya Liu
Notification policy severity: critical
email immediately
sms immediately
voice call after 2 min
Acknowledged at 03:14 by Tomasz Wrona
→ escalation stopped, pending pages dropped
A notification is only useful if it survives a bad night: a sleeping phone, a flaky provider, a responder who is already on another incident.
Each responder decides on their own profile whether to be texted, rung, or both. A voice call is the channel that gets through a silenced phone, which is why it exists as its own step rather than as a fallback. Each page can be acknowledged where it lands: the Acknowledge button in the email, a reply with the code in the text, or pressing 1 on the call.
A built-in sender works with no setup and includes a monthly allowance; past that you top up credits. Or connect your workspace’s own Twilio or Telnyx account and pay the provider directly — a workspace on its own provider is not metered by ZipLogger at all.
Attempts retry with backoff, and every attempt records its outcome, so a provider outage delays a page rather than losing it. The incident timeline shows exactly what was tried, to whom, and what came back.
Once somebody has acknowledged, a page still held back by a policy delay is dropped and a phone page is not retried. A message already handed to the provider cannot be recalled, so the last one in flight may still land — we would rather say that than pretend otherwise.
Duplicate alerts fold into the open incident instead of paging twice. Flood control caps how many incidents one workspace can raise in a minute, maintenance windows cover planned work, and an individual incident can be suppressed by hand.
Paging is email, SMS and voice, so there is nothing for a responder to download, sign into or keep notification permissions for. ZipLogger has no mobile app and sends no push notifications; the phone network is the delivery mechanism.
An incident is not a notification that already happened. It is a live object with a state, a responder, a timeline and the telemetry from its own window attached.
Triggered, acknowledged, resolved — with a state machine that knows which transitions are legal and applies them as a conditional update. An illegal move, or one that lost a race, changes nothing rather than half-succeeding.
Acknowledging claims the incident, stops the escalation and records who and when. It is the signal the rest of the system reads: pending pages stop, phone retries stop.
Log volume, error counts and query matches for the incident window, next to the equally long window before it. Plus request throughput, 95th-percentile latency and error traces, and the synthetic runs that failed — with the regions they failed in.
The same alert firing again joins the open incident instead of starting a new one. A cap on incidents per minute per workspace means a cascading failure does not turn into a hundred pages.
Scope a window to a service, an environment, a single alert rule or a single integration; a window with no filter matches everything. When several windows match, the most specific one is the one named on the incident, so you can see why it stayed quiet.
What fired, every notification attempt and its outcome, who was paged, who acknowledged, what was commented and when it resolved. The record a review needs is a by-product of handling the incident, not something anyone has to reconstruct afterwards.
Ask for an analysis and the prompt is assembled from the incident itself: its timeline, the live correlation figures for its window, and a sample of the failing service’s error logs from that same window. Nothing is sent that a workspace member could not already read on the incident page.
The answer is stored on the incident, so the team reads one analysis instead of each person paying for their own at three in the morning.
Every AI feature in ZipLogger runs on your own Anthropic, OpenAI or Google account. The key is verified when you save it, encrypted at rest and never shown again. It is on demand only: nothing reaches a model until somebody asks, and with no key configured the rest of the product is unaffected.
AI analysis INC-2291 · checkout-api
Window 03:02–03:18 vs previous 16 min
errors 1,284 baseline 31
p95 latency 4,910 ms baseline 240 ms
matched rule 1,190 baseline 0
Most errors are Npgsql timeouts on one
connection pool, starting 40s after the
03:01 release. Latency rose before the
error rate, which points at pool
exhaustion rather than a bad query.
Stored on the incident · visible to the team
ZipLogger writes its own alert rules over the telemetry it holds. It also accepts alerts from ten inbound sources, normalises them into the same incident model, and runs them through the same on-call, escalation and paging path.
Alarm state changes arrive as incidents, with the alarm’s own name and reason carried through.
Common alert schema payloads, mapped onto severity and the affected resource.
Alerting policy notifications, normalised into the same incident shape as everything else.
Monitor alerts, with the monitor name and transition preserved on the incident.
Grafana Alerting webhooks, including which rule fired and what it was evaluating.
Alert conditions and incident notifications routed into your on-call rota.
Standard Alertmanager webhooks, so an existing rule file needs no rewriting.
A failed workflow can raise an incident, which is useful when the failure is a deploy.
Build and job failures as incidents, on the same escalation rules as everything else.
Anything that can POST JSON. The escape hatch for the tool nobody has written an adapter for.
Already committed to PagerDuty or Opsgenie? Connect either one as a destination and keep it. ZipLogger raises the incident there as well, and an acknowledgement in that tool marks the ZipLogger incident acknowledged too, so a team can migrate gradually or run both while it moves across. It is an integration, not a dependency: nothing about ZipLogger’s alerting, on-call or escalation needs a second platform. All integrations →
This is the whole argument for running incident management where the telemetry already lives. Compare the two shapes.
An incident raised by a ZipLogger rule keeps the query that raised it, so “show me the lines that did this” is a link rather than a reconstruction from a timestamp in a notification.
Because the platform holds the telemetry, it can compare that window with the one before it without anybody choosing a time range by hand — and it can do it for logs, traces and synthetic runs at once.
From the error pattern on the incident you reach the trace, the affected users, the release that was stamped on those records, and the suspect commit behind it. That chain exists because it is all one dataset.
Telemetry, detection, investigation, incident management and on-call in one platform. Not five products with webhooks between them.
Incident management, on-call schedules and escalation come with ZipLogger rather than as another product priced per responder. SMS and voice are the one metered part: the built-in sender includes a monthly allowance and you can top up credits, or connect your own Twilio or Telnyx account and pay the provider directly.
No. Detection, incidents, on-call schedules, escalation policies and paging by email, SMS and voice call all run inside ZipLogger, and none of it depends on a second platform. If you already run PagerDuty or Opsgenie you can connect either one as a destination and keep it, but that is an option rather than a requirement.
No. ZipLogger has no iOS or Android app and does not send mobile push notifications. Paging is by email, SMS and voice call, and each responder chooses on their own profile whether to be texted, rung, or both. One upside worth naming: a voice call does not depend on an app being installed, signed in, or having notification permissions switched on.
It escalates on its own. An escalation policy is an ordered list of steps, each with its own delay, each targeting an on-call team or a named person. A background worker moves triggered incidents to the next step once that step’s delay has passed. Acknowledging stops the escalation and records who did it.
It stops the ones that have not gone out yet. A page held back by a notification policy’s delay is dropped once somebody has acknowledged, and an SMS or voice page is not retried. A message already handed to the phone provider cannot be recalled, so the last page in flight may still arrive.
Each schedule carries its own IANA time zone — Europe/Warsaw,
America/New_York — and shift boundaries are worked out in that zone. A rota
that hands over at 09:00 local keeps handing over at 09:00 local across a daylight saving
change, rather than drifting by an hour.
Your own alert rules over logs, product events, service health, latency and traffic; a failed health check; a failing browser journey; a Kubernetes problem detected in a monitored cluster; or an alert forwarded from a monitoring tool you already run. Ten inbound sources are supported, including AWS CloudWatch, Azure Monitor, Google Cloud Monitoring, Datadog, Grafana, New Relic, Prometheus Alertmanager, GitHub Actions, Jenkins and a generic webhook.
Only when you ask for an analysis, and only to the model provider whose key you configured yourself. Every AI feature runs on your own Anthropic, OpenAI or Google account; the key is verified when saved, encrypted at rest and never shown again. Nothing is sent that a workspace member could not already read on the incident page, and with no key configured the rest of the product is unaffected.
Yes. A maintenance window can be scoped to a service, an environment, a specific alert rule or a specific integration, and a window with no filter set matches everything. When several windows match, the most specific one is named on the incident, so it is clear afterwards why it stayed quiet.