Log File Merger

When an incident spans services, the story is scattered. One log holds the gateway, another the application, a third the database, and nowhere does the real sequence exist in a single place. Log File Merger stitches up to three logs into one stream ordered by timestamp, reconstructing the end-to-end timeline that no single file shows on its own.

Every non-blank line from every box is read, its timestamp extracted with a configurable pattern (a regular expression, defaulting to ISO-8601), and the whole combined set sorted ascending or descending by that extracted key. When two lines share the exact same timestamp text, the merge keeps them in their original relative input order rather than shuffling ties, in both sort directions — switching from ascending to descending reverses the chronological order of distinct timestamps without also scrambling same-timestamp lines against each other. Lines that carry no recognizable timestamp are set aside and placed at the start or end of the merged output, exactly as configured, keeping their own original relative order so stack traces, wrapped continuation lines, and banner text stay attached to sensible neighbors instead of being scattered by an incidental sort.

The result is a single, continuous, correctly ordered view of everything that happened, with per-input line counts shown live above each box so it is obvious how much of each source actually made it into the merge, and separate stats after merging for total lines, how many logs contributed, how many lines carried a usable timestamp, and the final output size in bytes.

• Merge up to three logs — gateway, application, and database (or any three sources) combined into one view.
• Sort by timestamp — ascending (oldest first) or descending (newest first), with ties between identical timestamps always broken by original input order regardless of direction.
• Configurable timestamp pattern — a regular expression, capture-group aware, so formats like DD/MM/YYYY or a custom prefix work as well as the ISO-8601 default.
• Timestamp-less lines handled explicitly — grouped at the start or end of the merged output as chosen, with their original relative order preserved rather than interleaved arbitrarily.
• Live per-input line counts — each of the three boxes shows its own line count as text is pasted or typed, confirming every source loaded before merging.
• Post-merge stats — total lines, number of logs that contributed content, how many lines had a usable timestamp, and the merged output size in bytes.
• Copy or download the merged stream as a single plain-text file.
• 100% local — nothing leaves the browser, no upload, no server round trip.

1. Paste up to three logs — one per box, in any order; the merge is driven entirely by extracted timestamps, not by which box a line came from.
2. Adjust the timestamp pattern if the source format is not ISO-8601 — put the part to sort on inside a capture group, or leave it as a plain match if there is only one group needed.
3. Pick a sort direction (ascending or descending) and where lines without a recognizable timestamp should land, at the start or the end.
4. Click Merge logs. The combined, sorted stream appears in the output panel below the settings.
5. Check the stats row — total lines, logs used, how many were successfully sorted by timestamp, and the output size confirm the merge behaved as expected.
6. Copy or download the reconstructed timeline for a postmortem, a ticket, or further processing.

Example 1 — End-to-end tracing. Three services each log a request separately: the gateway, the application, and the database. Merged and sorted by timestamp, the full path becomes visible in one stream: gateway accepts the request, app authenticates the user, database runs the query, gateway sends the response.

Example 2 — Multi-day archives. Several nightly log chunks from the same service, each covering one day, are merged into a single chronological stream spanning the whole period for a review or an audit.

Example 3 — Out-of-order collection. Logs pulled from two servers with slightly skewed clocks are merged and sorted by timestamp so the interleaving between them is close enough to compare cause and effect across services.

Example 4 — Newest-first triage. During an active incident, merging with descending sort puts the very latest events from all three sources at the top of the output, so the most recent activity across every system is visible without scrolling.

• True chronological sequence reconstructed across every input, not just within a single file.
• No more eyeballing which event from which service came first.
• Stable tie-breaking — lines sharing an identical timestamp keep their original relative order in either sort direction.
• Timestamp-format flexibility for any logging stack via a configurable regular expression.
• Clean, complete output — blank lines dropped, every remaining line and its timestamp preserved exactly as written.
• Private — all merging and sorting happens locally in the browser.