# Sysdig Inspect: a desktop interface for reading sysdig capture files > Sysdig Inspect is a graphical front end for the traces that sysdig collects on Linux, giving you a metrics overview, sub-second trends and drill-down into processes, files, network connections and system calls. It is a viewer, not a collector, and it works on capture files rather than on live systems. **draios/sysdig-inspect** — Sysdig Inspect - A powerful opensource interface for container troubleshooting and security investigation - Repository: https://github.com/draios/sysdig-inspect - Website: https://www.sysdig.org/ - Stars: 1,012 · Forks: 77 - Language: JavaScript - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/draios-sysdig-inspect ## It reads traces, it does not collect them Sysdig Inspect is described as a powerful opensource interface for container troubleshooting and security investigation, and the README states the prerequisite plainly: to use it you need capture files collected on Linux with sysdig. The tool itself is sysdig, and this is the interface for reading what it recorded. That boundary is the single most important fact about the project, and it shapes everything else. Inspect is not a monitoring agent, it does not attach to a running container, and it does not give you a live view of a production node. It is an analysis environment for a file. The consequence is a division of labour that is actually convenient: capture happens on the machine with the problem, under whatever privilege and timing that requires, and the analysis happens on your own machine, on your own time, with no risk of the analysis tool perturbing the system you are investigating. The README's example captures make the use case concrete. There is a 502Error.scap for troubleshooting an HAProxy 502 and a 404Error.scap for troubleshooting a 404 error from a leaky file, both in the capture-samples/ directory. These are the two classic symptoms of a misbehaving service, and the point of the tool is that both of them can be reconstructed from a trace rather than guessed at. The primary language of the repository is JavaScript, the default branch is dev, and the homepage is sysdig.org. The repository is not archived and the last push was on 2026-09-12, so work continues on the development branch. The audience is whoever is on call when a container misbehaves and needs the story of what happened rather than a snapshot of what is happening now. ## The overview tiles, and the drill-down that follows them The workflow the README describes starts with a summary and then narrows, and the design is built around that funnel. The overview page gives an out of the box, at a glance summary of the capture. Content is organised in tiles, each showing the value of a relevant metric and its trend, and the tiles are organised into categories. The tiles are the starting point for investigation and drill down, which is the key structural idea: rather than a wall of charts, you get a set of questions the capture can answer, each with a number attached. Clicking a tile shows the sub-second trend of that metric, and the README is emphatic about the granularity, sub-second, and about what it reveals. It says you will be amazed at how different your system, containers and applications look at this level of granularity. That is a real observation about traces rather than about averages: a periodic health check tells you a service was slow, and a sub-second trend tells you which call was slow and when it happened relative to everything else. Multiple tiles can be selected at once to see how metrics correlate, which is how a hot spot gets identified. Correlation here is a visual read, an overlay of two trends, rather than a computed coefficient, and that is worth keeping in mind when you report on it. From a tile you drill down into the underlying data. At that point you can either use the timeline to restrict what you are looking at, or drill down further by double clicking a line of data. What you arrive at is processes, files, network connections and much more, and the payload and system call visualisation goes further still. Every byte read or written to a file, provided the appropriate --snaplen parameter was used when creating the capture, and every byte sent to a network connection or a pipe, is recorded in the trace file. The README names two situations this answers directly: troubleshooting an intermittent network issue, and determining what a malware wrote to the file system. ## Running it: the container, the desktop installers, and the port mapping Two ways to run it are documented, and the container is the first one the README leads with. The Docker route is a single command: ```bash docker run -d -v /local/path/to/captures:/captures -p8080:3000 sysdig/sysdig-inspect:latest ``` The volume mount is the part that matters. Your capture files are mounted into the container at /captures, and the application reads them from there. The port mapping then exposes the web interface on port 8080 of the host, which forwards to port 3000 inside the container, and the README says the interface will be available in your browser at http://localhost:8080. The image is also on Docker Hub as sysdig/sysdig-inspect. The Dockerfile in the repository shows why the container is a reasonable option rather than a hassle. The base image is sysdig/sysdig:0.36.1, so the sysdig binary and its dependencies come along with it, and a Node.js runtime is installed through nvm with NODE_VERSION 10.5.0. The environment sets SYSDIG_SERVER_PORT 3000, SYSDIG_PATH /usr/bin and SYSDIG_SERVER_HOSTNAME 0.0.0.0, and the built application binary is added at /usr/bin/sysdig-inspect. The container exposes 3000 and has a healthcheck that curls http://localhost:3000/health every minute with a 20 second timeout. The desktop route offers installers for each platform: a macOS installer, a Windows installer, an RPM for Linux and a DEB for Linux, each behind a setns.run redirect. The changelog lives at the project's releases page. A third route exists for development, described in the package.json scripts. There is start:electron for the desktop shell, start:backend for the server, and start:webapp which serves the Ember front end and proxies to http://localhost:3000. That split, a separate backend and a separately served front end, is the architecture of the whole application. ## The Ember and Electron stack, and where the age shows The package.json describes an Ember application wrapped in Electron, and the version numbers in it are the story. ember-cli is at 3.12.1, and the dev dependencies include bower, brocolli-era tooling such as broccoli-asset-rev, ember-cli 3.12.1, ember-ajax, @ember/jquery at 0.6.0 and @ember/optional-features at 0.7.0, plus electron-prebuilt-compile 3.0.13 and electron-squirrel-startup 1.0.0. The repository has an .ember-cli file, a bower.json, ember-cli-build.js, an ember-electron/ directory, and testem.js and testem-electron.js test configurations. This is an Ember application from the period when Ember was a common front end choice, packaged for the desktop with Electron and served in the container as a web app. The build scripts confirm the three-target model. package:mac, make:mac and make:linux use ember electron:package and ember electron:make with a platform flag, and there are Windows equivalents, package:win and make:win, with their own .bat scripts for setup, clean, bundle and running the backend. make:docker-image builds the container, and setup runs npm ci followed by scripts/install. The Dockerfile's Node 10.5.0 is the clearest signal of the vintage. Node 10 reached end of life years ago, and while it is pinned deliberately so the build reproduces, it does mean the container's runtime is not receiving security updates from the Node project. The base sysdig image at 0.36.1 is similarly old. The release timeline is consistent with that. The version in package.json is 0.12.1, the release list shows 0.12.1 on 2026-07-17, 0.12.0 on 2024-07-19 and 0.11.0 on 2024-05-14. So 0.12.0 and 0.11.0 are two years old, and 0.12.1 is a recent patch on top of an old minor line. The default branch is dev, which is where the next work is going. For an adopter, the practical consequence is that you are installing a tool whose front end is built on a framework generation that no longer receives updates. That is fine for a locally-run analysis tool with no network exposure, and it is a different proposition for something you would run in a shared environment. ## The licence, and what the README does and does not say The licence situation needs a careful reading, because the two statements do not match on their face. The README says Sysdig is licensed to you under the GPL 2.0 open source license, and links to the COPYING file in the sysdig repository. The package.json for sysdig-inspect, however, declares the licence as the GNU General Public License without a version, and the repository listing carries its own COPYING file. The repository metadata classifies the licence as a custom one that GitHub cannot categorise, and there is no LICENSE file at the top level, only COPYING. For a person running this on their own laptop to look at a capture file, none of this matters. For an organisation considering Sysdig Inspect as part of a commercial troubleshooting workflow, it does. The two questions to answer before adopting are which version of the GPL applies, and whether the GPL obligations reach whatever you distribute. The GPL 2.0 named in the README and the unspecified GNU General Public License in the package metadata could be different versions, and the difference between GPL 2.0 and GPL 3.0 is not a formality. The honest position is that the repository's own texts are inconsistent, and the files in the repository, plus an internal legal review, are the way to settle it. Sysdig Inc. is the author named in the package.json. What the README does not document is worth listing too. There is no statement about which sysdig versions produce captures that this build can read, no documented capture file size limits, and no guidance on how to use the tool against captures from a production node with sensitive payloads in them. That last point is the one to think about before you load a real capture file on a shared machine, since with an adequate snaplen the trace contains every byte written to disk. ## Sysdig Inspect against working on the trace directly The obvious alternative is to skip the interface and use the sysdig command line, and the README supports that in two ways. It points at the sysdig user guide for an introduction to the tool, with examples that guide you through the command line and filtering syntax, and it notes that you can switch at any time into sysdig mode and look at every single system call from within the interface. That last point is the key design decision and it deserves emphasis. Inspect is not a replacement for the command line, it is a layer on top of it that you can drop out of at any moment. The difference in approach is that the interface gives you the same underlying data through a graphical funnel, the overview tiles narrowing to a sub-second trend, then to a drill-down, and when you need the raw thing you go to sysdig mode and work with the syscall stream directly. For a person who knows sysdig well, the interface is a way to find the interesting region of a large capture quickly. A capture of a busy host is far too large to read linearly, and the tile overview is a way of asking the file structured questions and then narrowing to the part that matters. The drill-down with the timeline restriction is what makes a multi-minute capture usable, because you can restrict the window and then read the events inside it. The other alternative is a different class of tool entirely: a general-purpose observability agent and dashboard, which attach to a running system and report metrics and traces continuously. The difference in approach is capture versus observation. An observability agent tells you what is happening now, and it tells you the same way for every host. A capture file tells you exactly what happened, in full detail, on one host, at one moment, including the bytes. Sysdig Inspect is in the second category, and for a post-mortem on a fault that has already happened it holds information that a sampling agent simply did not record. The cost of the second category is what you already paid to collect the capture. And that cost is the constraint to plan around, because the capture is taken on a host with a problem, at a moment when you have to decide to take it, and a file that contains every byte written to disk is both large and sensitive. ## Conclusion Adopt Sysdig Inspect when you have sysdig capture files from a Linux host or container and need to investigate them faster than the command line allows, especially for intermittent network faults or unexpected filesystem writes. Do not adopt it as a live monitoring tool, since it works on captured traces rather than on a running system, and check the licence terms in the repository before using it in a commercial engagement. Verify first that your captures were taken with the right snaplen if you need payloads, that your sysdig version produces files this build can read, and that the release you install matches the 0.12.1 line, since 0.12.0 and 0.11.0 shipped two years earlier. ## FAQ ### What does Sysdig Inspect need in order to work? It needs capture files collected on a Linux system with sysdig. The README gives the quick start as `sudo sysdig -w filename.scap`, and the repository ships two example captures, 502Error.scap and 404Error.scap, for troubleshooting. ### How do I run Sysdig Inspect in Docker? Mount your captures directory and publish the port with `docker run -d -v /local/path/to/captures:/captures -p8080:3000 sysdig/sysdig-inspect:latest`, then open http://localhost:8080. The container image is also published on Docker Hub as sysdig/sysdig-inspect. ### Can Sysdig Inspect show the data written to files and network connections? Yes, provided the appropriate --snaplen parameter was used while creating the capture. The README says every byte read or written to a file, to a network connection or to a pipe is recorded in the trace file and can be observed in the interface. ### What licence applies to Sysdig Inspect? The README says Sysdig is licensed under the GPL 2.0 open source license and links to the COPYING file in the sysdig repository, while the sysdig-inspect package.json declares the GNU General Public License without a version. The repository carries its own COPYING file, so the files in the repository are the place to settle which terms apply. ## Sources - [draios/sysdig-inspect on GitHub](https://github.com/draios/sysdig-inspect) - [Issues](https://github.com/draios/sysdig-inspect/issues) - [Project website](https://www.sysdig.org/) - [README](https://github.com/draios/sysdig-inspect/blob/dev/README.md) - [Releases](https://github.com/draios/sysdig-inspect/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/draios-sysdig-inspect