SayDeploy Plain comparisons of developer tools, AI coding tools included

How to tail logs from several services for backend engineers

Follow these steps to watch logs from several backend services at once, and compare tools that show each service's output in one place.

By SayDeploy ยท

SayDeploy is published by LunarWerx, which makes some of the tools compared here.

Tail logs from several services by naming each one, starting them in dependency order, and watching their output in one view or in clearly labeled windows. A tool such as DevWebUI can show each managed server's logs next to its status, CPU and memory. [1]

OptionWhat it doesCost
DevWebUIStarts, stops and restarts local dev servers from one dashboard, and shows each server's status, CPU, memory and logs. [1]Free, and core features need no account. [1]
Terminal commandsnot publishednot published
Development environment run configurationsnot publishednot published

What you need before you start

Before you follow logs from several services, each service needs its own working folder and a start command that runs it on its own. Check that the runtime, package manager, and database each service depends on are installed and can start without errors.

Write down the port each service uses. A port still held by an old process can stop a service from starting, and its logs may then look broken when the real problem is the port.

Decide which services must run together, such as an API, a background worker, a queue, and a database, and note which ones depend on others so you know what to start first. Give each service a short, clear name that you can spot in a log line, since the name is the fastest way to see where a message came from.

Settle on where logs go, either the terminal each service runs in or a file the service writes to. Finally, make sure you can stop and restart each service cleanly, so a stuck process does not leave you reading old output.

Step by step

  1. Start with the list of services from the section above. Confirm which ones produce logs and where each one writes them.
  1. Start the services in dependency order. Begin with the database and any queue, then the APIs, then the workers that depend on them. Wait for each one to report that it is ready before starting the next.
  1. Open one view for all the output at once, or give each service its own window and label it clearly. Pick one approach and use it every time so the setup stays familiar.
  1. Follow each stream as it arrives. Look for the first error in time order, because later errors are often caused by it.
  1. Filter by service name or by log level when a stream becomes too busy. Filter only on what you need so the cause does not get hidden.
  1. Include a request identifier in log lines when several services handle the same request. Then one search can follow that request across services.
  1. Keep log files when services write to disk, and clear or rotate them when they grow large so older output does not hide new errors.
  1. Save the start order and commands once the setup works, so the same group of services can be started and followed again later.
  1. Add automation only after the manual process is reliable. A script or tool should remove repetition without hiding which service produced which line.

Tools that can do it

DevWebUI is made by the team that publishes this site. It starts, stops and restarts local dev servers from one dashboard, and shows each server's status, CPU, memory and logs. [1] Errors from those servers are collected into one log that merges repeats and is kept across restarts, and each file:line link opens in your editor. [1] DevWebUI reads one small file per repo to know which servers to run, and it writes changes made in the interface back to that file. [1]

A devwebui command-line tool talks to the same REST API, so you can control processes from scripts without opening the interface. [1] When a port is already taken, DevWebUI shows which process holds it and can free the port if you ask. [1] DevWebUI can start a repository's Docker Compose containers first, wait until their ports are ready, and set up the database connection details. [1]

There is a prebuilt Windows x64 app, and on other systems you run DevWebUI from source with Bun. [1] The tray app is Windows-only for now. [1] On Windows you download devwebui-windows-x64.exe from GitHub Releases. On any system you can run bun install and then bun run dev. [1]

Terminal commands and development environment run configurations are the other options on this page. This page has no published details for them, so check each one's documentation for how it shows output from several services together, whether it can filter that output, and which operating systems it supports.

Common mistakes to avoid

Reading the output of only one service makes it hard to see a failure that started in another. Keep every service visible, or check each one when something fails.

Starting services in a random order can leave a backend waiting on a database that is not ready yet. Its logs will then show connection errors that look like a backend problem.

Reusing a port that an old process still holds can make a new service appear to fail while the old one keeps answering requests.

Forgetting to include a request identifier makes it hard to connect messages across services.

Restarting a service can push its first error out of view, so copy that error before you restart.

After an unclean shutdown, DevWebUI loads your projects but starts nothing automatically, so check which services are running before you trust what the logs show. [1]

Keeping log files without a size limit can fill the disk and slow the machine.

Frequently asked questions

How can backend engineers tail logs from several services at once?

Backend engineers can tail logs from several services by naming each service, starting them in dependency order, and watching their output in one view or in clearly labeled windows. Filtering by service or log level keeps a busy stream readable. Adding a request identifier to log lines lets one search follow a request across services. The steps in this guide cover the setup before any tool is chosen.

Can DevWebUI show logs from several services in one place?

DevWebUI shows each managed server's logs next to its status, CPU and memory in one dashboard. [1] It also collects errors into one log that merges repeats and is kept across restarts. [1] Each file:line link opens in your editor, so an error can be traced to its source. [1] Whether this fits depends on how your services are run, so check the setup against the steps above.

Is DevWebUI free for backend engineers?

DevWebUI is free, and its core features need no account. [1] It is open source under the MIT License. [1] A prebuilt Windows x64 app is available, and on other systems the tool runs from source with Bun. [1] Check the license and platform details before adopting it for a team.

Does DevWebUI keep error logs after a restart?

Errors are collected into one log that merges repeats and is kept across restarts. [1] Errors from an earlier run stay in the log when the servers start again, which can help when a failure only appears after a restart. [1] Each file:line link opens the matching line in your editor, so the error can be traced without searching through terminal output. [1]

What should backend engineers check before choosing a tool for several services?

Check how the tool shows output from several services at once, whether it can filter by service and log level, and whether it keeps logs across restarts. Confirm which operating systems it supports and whether its install steps match your machine. Also check whether it can start services in order and what happens to running services after an unclean shutdown. Read each option's own documentation before deciding, since this page does not publish details for every option.

DevWebUI is free, and its core features need no account. [1]

Try DevWebUI

Sources

  1. DevWebUI's own description of itself (the product of this site's publisher)

Related comparisons