--- title: The Search Came Back Empty description: When someone finally asks who connected to a system and when, the answer fails for four boring reasons. All four can be fixed before the question arrives. image: https://pathinsights.io/hubfs/s1_hero-1600x900.png --- [![logo](https://pathinsights.io/hs-fs/hubfs/Artboard%204@4x.png?width=200&height=86&name=Artboard%204@4x.png "logo")](https://pathinsights.io) Search toggle - [Home](https://pathinsights.io) - [Resources](https://pathinsights.io/insights) - [Contact Us](https://pathinsights.io/insights/the-search-came-back-empty#contact) [Follow us on Facebook](https://www.linkedin.com/company/pathinsights) [![logo](https://pathinsights.io/hs-fs/hubfs/Artboard%204@4x.png?width=200&height=86&name=Artboard%204@4x.png "logo")](https://pathinsights.io) - [Home](https://pathinsights.io) - [Resources](https://pathinsights.io/insights) - [Contact Us](https://pathinsights.io/insights/the-search-came-back-empty#contact) Search toggle [![](https://pathinsights.io/hs-fs/hubfs/Artboard%201@4x.png?width=299&height=86&name=Artboard%201@4x.png)](https://pathinsights.io) - [Home](https://pathinsights.io) - [Resources](https://pathinsights.io/insights) - [Contact Us](https://pathinsights.io/insights/the-search-came-back-empty#contact) [Follow us on Facebook](https://www.linkedin.com/company/pathinsights) Search toggle What are you looking for? Search # The Search Came Back Empty 16 Oct 2026 ![Picture of Francisco J Peña](https://pathinsights.io/hs-fs/hubfs/Imported%20images/1727142866446%3Fe=1733961600%26v=beta%26t=PZB-1WDzWivHhRvCIEYOC61KkAr30O73eaFc9UPsTzc.jpeg?width=40&name=1727142866446%3Fe=1733961600%26v=beta%26t=PZB-1WDzWivHhRvCIEYOC61KkAr30O73eaFc9UPsTzc.jpeg) [Francisco J Peña](https://pathinsights.io/insights/author/francisco-j-peña) ![The search came back empty. Who connected to a system, and when: four places a real answer goes wrong even when the logs exist, and one page that fixes them.](https://pathinsights.io/hubfs/s1_hero-1600x900.png) Sooner or later somebody asks a business a question it did not plan for: over the last few months, who connected to this system, and when? The question never arrives on a schedule. It shows up after something else, from a direction nobody was watching, and it is usually urgent by the time it lands. What I want to walk through is not how to build a perfect record. It is the four places I have watched a real answer go wrong even when the logs existed, because every one of them can be settled before anyone asks. ## The wrong name Here is the first thing I have seen happen. Somebody hands over a short list of people and asks for their connection history. The natural move is to search the logs for the names as everyone knows them, which in practice means their email addresses. The search comes back empty. No sessions, no connections, nothing. That result gets read as "these people never connected." It is a clean, satisfying answer, and it can be wrong. A remote-access gateway authenticates accounts rather than people, and the account name it records is often not the address a person uses for email. It can be a directory identifier, a sign-in name that predates a rename, or a service account somebody set up for a project. Search on the address everybody knows and you can get zero results for someone who connected every working day. When the same search was run on the accounts the gateway actually authenticates, the full history was there. Nothing was missing. The first query had simply asked the wrong question in a way that looked like an answer. The habit I would build: keep one page, not a directory export, that maps each person to the identity your gateway sees. When someone leaves, the page says which identities to close. When someone asks a question, the page tells you what to search for. It takes less time than you expect, and it is the difference between "no access" and "no results." ## The clock you did not know was running The second thing: logs live in more than one place, and the places keep them for different lengths of time. The device that authenticates a connection usually keeps its own session log, and that local store is short and depends on the model: on many devices it holds hours or days, and on some it is wiped by a restart, unless somebody set it deliberately. If the same events are also shipped to a central log store, that store can hold them for as long as you decided to pay for, which is a decision many owners have never consciously made. The practical consequence is that the moment a question arrives, a clock is already running on the most detailed copy of the evidence. If the question is about last week, you may have days to preserve the local log before it rolls over. If it is about last spring, the only copy that still exists is whatever the central store kept, and only if the central store was actually receiving those events at the time. What I would do: find out today what your gateway keeps locally and for how long, whether those events are shipped anywhere else, and how long that place keeps them. Write the two numbers down next to each other. Then adopt one rule for the day a question arrives: preserve first, search second. Export the local log before anybody starts filtering it. ## The records that will not pair The third thing is subtler. A connection history is built from pairs: a login and the logout that belongs to it. Pair them and you can say how long someone was connected. Do not pair them and you can only say that they connected. In practice a meaningful share of logins have no matching logout. Sessions time out, laptops close, tunnels drop and reconnect, and the log records the start without the end. When that happens, there is no honest total connected time for that person. The figure is not established, and no smaller number substitutes for it. The temptation is to produce a number anyway. A spreadsheet has a column for it, and an estimate feels better than a blank. The estimate is the mistake. A connected-time figure that quietly includes guesses will be read as a measurement by everyone downstream, and if it is ever challenged, it takes the credibility of the entire answer down with it. Decide in advance how you will report a record that cannot be paired. Report what paired, report what did not, and leave the total blank with the reason written next to it. A blank with a reason survives scrutiny; a number with a hidden assumption does not. ## The claim that outgrows the log The fourth thing is the one I think about most. Say the logs show that every session for the people in question came in through the gateway and was authenticated properly. That is a real finding, and it is worth stating. Here is what it does not say: that there was no other way in. A gateway log records the traffic that went through the gateway, and it is silent about anything that never passed through it. The question "did they come in the proper way" and the question "was the proper way the only way" are two different questions, and no amount of gateway history settles the second one. The second question has its own answer and its own work, and the honest move is to say so rather than let the first answer stand in for it. What I would do: when you write up an access answer, write the boundary into it in plain words. "This covers connections through the gateway. It does not establish that no other path existed." That sentence feels like a weakness when you write it, and it is the sentence that makes the rest of the document trustworthy, because a reader can see exactly what it covers and exactly what it does not. ## Who is asking, and on whose authority One more, and it is not technical. A request for the connection history of named people is a request for a record about people. Before producing it, know who is asking, in what role, and whether that role carries the authority to receive it. Most of the time the answer is obvious. The discipline is to check anyway, and to write down that you did, because the day it is not obvious is the day the record matters most. ## One page, written before you need it Everything above fits on a single page that you can write this month and never think about again until the day it earns its keep: The identity your gateway authenticates for each person, and who owns updating that list. What the gateway keeps locally, for how long, where those events are also stored, and for how long there. The rule for the day a question arrives: preserve the local log first, then search on the mapped identities, then report paired and unpaired sessions separately with the total left blank where it cannot be established. The boundary sentence you will put in every access answer, and the name of whoever would have to answer the larger question if somebody asked it. Who may request a record about named people, and how you confirm that before you produce one. I have seen this question land on a well-run, well-intentioned business, and I have watched the answer wobble for exactly these reasons. All of it fits on one page, written while nobody is waiting on it, with the willingness to put "not established" in writing where that is the truth. --- *I write about what it takes to keep a small company's operations answerable, from inside real operations. More at pathinsights.io.* ### Share: [Share on Facebook](http://www.facebook.com/share.php?u=https://pathinsights.io/insights/the-search-came-back-empty&utm_medium=social&utm_source=facebook) [Share on LinkedIn](http://www.linkedin.com/shareArticle?mini=true&url=https://pathinsights.io/insights/the-search-came-back-empty&utm_medium=social&utm_source=linkedin) [Share on X](https://twitter.com/intent/tweet?original_referer=https://pathinsights.io/insights/the-search-came-back-empty&utm_medium=social&utm_source=twitter&url=https://pathinsights.io/insights/the-search-came-back-empty&utm_medium=social&utm_source=twitter&source=tweetbutton&text=The%20Search%20Came%20Back%20Empty) ## Francisco J Peña With over a decade of experience in operations and analytics, I specialize in transforming business processes through data-driven insights, automation, and digital solutions. At Path Insights LLC, I focus on helping businesses streamline their operations, modernize executive reporting, and make faster, informed decisions by leveraging advanced data analytics. ## Related posts Search [Exposure, Data, Decisions](https://pathinsights.io/insights/exposure-data-decisions) ![Artboard 4@4x](https://pathinsights.io/hs-fs/hubfs/Artboard%204@4x.png?width=500&name=Artboard%204@4x.png "Artboard 4@4x") One team to fix your processes, connect your systems, and deliver insight you trust. [www.pathinsights.io](http://www.pathinsights.io) | [Privacy Policy](https://pathinsights.io/privacy-policy) [Follow us on Facebook](https://www.facebook.com/61569388859737) [Follow us on Facebook](https://www.linkedin.com/company/pathinsights/) Cookie settings [Privacy policy](https://pathinsights.io/privacy-policy)[Privacy contact](mailto:franciscojpena@pathinsights.io) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Francisco J Peña", "url" : "https://pathinsights.io/insights/author/francisco-j-peña" }, "dateModified" : "2026-10-16T19:05:35.887Z", "datePublished" : "2026-10-16T19:05:35.000Z", "headline" : "The Search Came Back Empty", "image" : [ "https://pathinsights.io/hubfs/s1_hero-1600x900.png" ], "mainEntityOfPage" : { "@id" : "https://pathinsights.io/insights/the-search-came-back-empty", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://pathinsights.io/hubfs/Artboard%201@4x.png" } } } ```