dlogify
01

New: Replay

The ticket says what failed. Replay shows how it got there.

Open a ticket and watch the logs of all your services arrive in order, up to the moment of the error. When the cause started somewhere else, you see it.

Start free

No card. One project, 5M events a month, 7 days of replay.

highorders · Example ticket

Database connection pool exhausted in orders

Requests to orders fail while waiting 30 s for a database connection. Probable cause: more concurrent queries than the pool can serve.

14:22:0010:00 before ticket

188 lines, 4 errors, 4 warnings
124 lines, 2 errors, 2 warnings
1,442 lines, 2 warnings
PlayedNot playedWarningsErrorsNo linesOther ticketOne column is 15 seconds.
Lines, warnings and errors per service
orders188 lines4 warnings4 errors
billing124 lines2 warnings2 errors
gateway1,442 lines2 warnings0 errors
auth120 lines0 warnings0 errors
mailer60 lines0 warnings0 errors
search60 lines0 warnings0 errors

All services, lines up to the cursor

No lines up to this moment.

Example data. The player is the one in the product; the notes beside it are ours, for this page. In the product you see only the lines, and the conclusion is yours.

02

Why

An error's cause rarely sits next to the error.

With the ticket alone

  • What failed, how often, the stack trace and a probable cause.
  • The 20 lines before the error and the 10 after, from one service.
  • At 100 logs a second, those 20 lines cover 0.2 seconds.

With Replay

  • Everything the project logged in the 15 minutes before, and back up to 24 hours.
  • Every service on one time axis, so a cause in another service is in view.
  • Warnings and errors marked on the timeline, so you jump to them instead of scrolling.
03

Investigate

The questions you ask after an incident.

What happened just before?

Play the logs that led to the ticket at 1x, 10x or 60x, and go back up to 24 hours. Playback stops at the ticket, and up to 5 minutes after it can be read.

Where did it start?

Each service has a row, with its volume and its worst level. Click a service to read only its lines.

Has it happened before?

An error group's history shows occurrences, tickets and a weekday and hour heatmap. Each ticket opens its own replay.

Did a release change it?

The group's history marks the releases that reported the error, next to its occurrences.

04

The evidence

Raw lines. Nothing filtered, nothing interpreted.

No AI in the replay

No generated causes or summaries over the lines. It shows the evidence and leaves the conclusion to you.

Redacted before it is stored

Lines go through the same redaction as everything else, so emails, tokens and IP addresses appear masked. Each message is cut at 2 KiB.

A gap never looks like silence

If lines could not be stored, the replay says how many and when. Time before a project's history started is marked as such.

You can turn it off

An admin can turn off the log history of any project. Retention follows your plan, and lines past it are deleted.

Lines are written every 5 minutes on Free and every 2 minutes on paid plans, so the last minutes of a new ticket arrive shortly after it. Replay starts from a ticket: it is not a log search. trace and debug lines appear only if you send them.

Read the Replay guide
05

Get started

From sign-up to your first replay.

  1. Step 1

    Create your account

    Free, without a card.

  2. Step 2

    Send your logs

    Two lines in your deploy with the Node.js, Python or Go SDK, or an OpenTelemetry Collector.

  3. Step 3

    Open a ticket and press Replay

    Replay needs no setup: it reads the lines stored for the project.

Node.js

npm i @dlogify/node
LOGIFY_API_KEY=lgf_live_… node --import @dlogify/node/register server.js

Python

pip install dlogify
LOGIFY_API_KEY=lgf_live_… logify run -- python app.py
06

Plans

Replay is on every plan. Only the days change.

Free

7 days

of replay and group history

Pro

30 days

of replay and group history

Team

90 days

of replay and group history