> ## Logs Explorer & multiverse map > Search and visualize logs across multiple execution paths in Antithesis test runs with the Logs Explorer tool. > Fetch the complete documentation index at: https://antithesis.com/docs/llms.txt > Use this file to discover all available pages before exploring further. --- When you test with Antithesis, we run your software on multiple parallel instances to find unexpected behaviors in your code. The [Logs Explorer](#the-logs-explorer) allows you to search across all the execution paths explored during the test. The [multiverse map](#the-multiverse-map) gives you a visual tree overview of all execution paths, with events that match the current search condition marked as dots. You can use the Logs Explorer and multiverse map together to: - **Investigate** production events in a powerful simulation - **Visualize** when and where events occur in a test run - **Improve** your testing by identifying gaps > **Note** > > For each simulation hour within the Antithesis environment, Antithesis will provide 200 MB of searchable log storage, and container image storage for a customer for 60 months. ## The Logs Explorer The Logs Explorer has powerful search capabilities. You can: - Use literal text or regular expressions to search for specific fields in logs. - Search for specific assertion, test command or fault injector logs. - Search for a set of logs using logical search patterns (event X AND event Y) and temporal queries (event X but only when preceded by event Y). For example, the following search looks for an assertion where the message contains the text "put requests", preceded by a network restore fault within 2 seconds: For the full set of options, see the [Logs Explorer reference](/docs/reference/logs_explorer_search/). Events stream in during a test run, so you can search while tests are still running. Clicking on any search result will bring up the full log history for that execution path. To investigate further, you can press the **Debug event** button to kick off a [multiverse debugging](/docs/product/debugging/advanced_multiverse_debugging/overview/) session from the log viewer: ### How to launch the Logs Explorer You can access the Logs Explorer in the following ways: - From the **Recent runs** page, click the **Explore Logs** button for any listed run. - From the **Logs Explorer** page, select the run from the list of recent runs. You can filter the runs by the Run ID found at the bottom of each triage report. - From a triage report, click the **Explore Logs** button next to the report title. ## The multiverse map The multiverse map is a visualization of a complete Antithesis test run: Each branch on this tree is a distinct timeline, in which Antithesis explores a different execution path through your system. [This page](/docs/product/debugging/advanced_multiverse_debugging/moment_branch/) provides a deeper explanation of the multiverse Antithesis builds in each test run. Instances of the events you searched for appear as dots: Clicking on any dot brings up the corresponding logs. Search for particular [fault types](/docs/reference/event_logs/#fault-injector-logs) to understand how frequently they occurred, or search for specific log lines followed by faults to see how often a particular function encounters a fault condition. ### How to view the multiverse map After you start a search, switch to the `Map` tab on the event search for this view. Right click on the map for zoom and view options. ## Common workflows This section suggests ways to use the Logs Explorer and multiverse map to investigate your logs. ### Investigate something you saw in production **Use case:** You saw an ominous log line in production but didn't have enough information to troubleshoot. Antithesis runs your software in a simulation that's much more hostile than production, and does so in massively parallel fashion. Therefore, any rare event you encounter in production very likely appears multiple times in an Antithesis test run, making it easier to investigate and debug. You can search for any line from your production logs, and layer in additional searches to reveal correlations with other events. Temporal relationships, where `event X is PRECEDED_BY event A` or `event X is NOT PRECEDED_BY event B`, can be especially helpful. To debug further you can launch a [multiverse debugging](/docs/product/debugging/advanced_multiverse_debugging/overview/) session and replay the bug as it happens in the test run. You can (and really should) also convert the event to a [test property](/docs/introduction/how_antithesis_works/#how-does-antithesis-identify-bugs) so future test runs will return a finding if it fails -- either [using our SDKs](/docs/reference/sdk/), or by talking to one of our customer success engineers. ### Investigate cascading failures **Use case:** You want to understand whether failures are independent or caused by an upstream failure. For example, say you see two failing properties, "Node joins cluster" with 4 failures and "Data replicates to all nodes" with 30 failures. You want to see if any of the replication failures are independent bugs, or just downstream of the node failing to join the cluster in the first place. To investigate this, you can use temporal search. Use a **Not preceded by** query to search for replication failures that were not preceded by a failure to join the cluster. ### Check for clusters of failures **Use case:** You want to understand the distribution of failures. Switch to the **Maps** tab and search for a type of failure. If there are many dots clustered on the same branch, it is likely that they share a root cause. Pick one event from the cluster for further investigation. ### Audit new changes under test **Use case:** You want to observe the behavior of some new code changes under test and improve test coverage. If your new changes are on a feature branch, you can [run a one-off test](/docs/product/understanding_test_results/reports/findings/#check-if-a-feature-will-cause-a-regression). Let's say you want to improve test coverage for leader elections in your database. Search for leader election events and to see how frequently they happen, and how early or late in the test run. Say you find leader elections too infrequently in the test run. You click through the leader election event logs and see that the leader election happened when 5 out of 9 nodes are dead. You can now search for node kill events to see if they're happening as frequently as you expect. If there are too few node kills, you might need more aggressive faults. If you see a good number of node kills then maybe you need more test scenarios with few nodes, to trigger more leader elections.