If you are comparing PagerDuty alternatives, the useful question is not which tool has more escalation settings. It is where your responder ends up after the phone rings. ZipLogger runs on-call schedules, escalation and paging inside the platform that already holds the logs, traces and metrics — so the incident opens onto the evidence instead of onto a link.
Observability + incident management + on-call · Or keep your current pager as a destination
These are the parts teams usually buy a dedicated pager for. In ZipLogger they are built in, and they run on the same data as everything else.
Teams with members and roles. Rotations by hours, days or weeks from a rotation start, each schedule in its own IANA time zone. Overrides carry a reason and an end time, then the rotation resumes. The team page shows who is on call now and who is next.
Ordered steps, each with its own delay, each targeting an on-call team or a named person. A background worker advances an unacknowledged incident to the next step on its own, using a conditional update so a race with an acknowledgement cannot double-page.
Email, SMS and voice calls through Twilio or Telnyx. Use the built-in sender with its monthly allowance and credits, or connect your own provider account and pay them directly. Acknowledging stops the escalation and drops pages that have not gone out, and the page itself can do it: the button in the email, a reply with the code in the text (Twilio), or pressing 1 on the call. Incidents can also post to Slack, Microsoft Teams, Discord or Telegram.
A state machine that knows which transitions are legal, deduplication so a repeat alert joins the open incident, flood control per workspace, maintenance windows, and a timeline that records every notification attempt and its outcome.
ZipLogger’s own rules over logs, events, service health, latency and traffic — plus ten inbound sources including CloudWatch, Azure Monitor, Google Cloud Monitoring, Datadog, Grafana, New Relic, Prometheus Alertmanager, GitHub Actions and Jenkins.
On demand, on your own Anthropic, OpenAI or Google key. The prompt is built from the incident, its timeline, its correlation figures and a sample of the service’s errors, and the answer is stored on the incident for the whole team.
This is a difference in architecture rather than a longer feature list, and it shows up at 3am.
Two systems, and the interesting part starts after the handover.
One system, and the incident already carries its own telemetry.
Concretely: an incident raised by a ZipLogger rule keeps the query that raised it, so the matching log lines are a link rather than a reconstruction from a timestamp in a notification email.
These are different kinds of product that overlap on incidents and on-call. The honest split, and we would rather you find this out here than after migrating:
To be explicit: this is not a feature-for-feature replacement for a dedicated incident-response suite, and we are not claiming it is. What it does claim is the list above, all of which is built and running today.
PagerDuty and Opsgenie can both be connected as incident destinations. ZipLogger raises the incident in that tool as well as its own, and an acknowledgement there marks the ZipLogger incident acknowledged too, so the two do not drift apart.
That makes a gradual move possible: point detection at ZipLogger first, keep paging where your rotas already live, and move the on-call side over later — or never, if the existing setup works. Teams also run both permanently, with one team on each.
Nothing about ZipLogger’s alerting, on-call or escalation requires a second platform. The destination is there for teams who want it.
Incident INC-2291 · checkout-api · critical
detected by ZipLogger rule
raised in ZipLogger
PagerDuty (destination)
acknowledged in PagerDuty 03:14
→ ZipLogger incident acknowledged
→ escalation stopped
→ pending SMS dropped
Investigation stays in ZipLogger
errors, traces, release, commit
Incident management, on-call schedules and escalation come with ZipLogger rather than being priced per responder. SMS and voice are the metered part: a built-in sender with a monthly allowance and credits, or your own Twilio or Telnyx account billed by the provider.
ZipLogger can take over the job most teams buy a pager for: on-call schedules with rotations and overrides, ordered escalation policies with per-step delays, and paging by email, SMS and voice call, with acknowledgement stopping the escalation. It is not a feature-for-feature replacement, and it is a different kind of product — an observability platform that runs the incident workflow over telemetry it already holds, rather than a dedicated incident-response suite.
A standalone pager routes a notification; it does not hold your logs, traces or metrics. Here the incident and the telemetry are the same system, so the incident page already carries the comparison between its own window and the window before it — log volume, error counts, query matches, request throughput, 95th-percentile latency and failed synthetic runs — and links straight to the error pattern, the trace and the release.
Yes. PagerDuty and Opsgenie can both be connected as incident destinations. ZipLogger raises the incident there as well, and an acknowledgement in that tool marks the ZipLogger incident acknowledged too, so you can migrate gradually or run both while a team moves across.
No. There is no iOS or Android app and no mobile push notifications. If a native on-call app is a requirement for your responders, that is a real reason to stay where you are. ZipLogger pages by email, SMS and voice call, and each responder chooses on their profile whether to be texted, rung, or both.
It suits engineering teams already looking for log management and tracing who would rather not buy incident response separately: the responder stays in one tool from the page to the root cause, and on-call comes with the platform rather than per seat. Teams whose incident process is owned outside engineering, or who need a dedicated response suite, are usually better served by a specialist product.
Ten inbound sources: AWS CloudWatch, Azure Monitor, Google Cloud Monitoring, Datadog, Grafana, New Relic, Prometheus Alertmanager, GitHub Actions, Jenkins and a generic JSON webhook. Alerts from any of them are normalised into the same incident model and run through the same on-call, escalation and paging path as ZipLogger’s own rules.
We will not quote someone else’s prices here, because they change and a stale comparison is worse than none. What we can say about ours: incident management, on-call and escalation are part of the ZipLogger platform rather than a separate per-responder product, and the metered part is SMS and voice — a built-in sender with a monthly allowance and top-up credits, or your own Twilio or Telnyx account paid directly to the provider. See the plans →