Comparing Astrina live traffic with server logs sounds simple until the first mismatch appears. One report says 18 visits. The log shows 24 requests. That gap usually has a reason, and the reason is often boring in the best possible way: a redirect, a bot, a proxy, or a timestamp that drifted by 60 seconds.
The job is not to force both numbers to agree at any cost. The job is to make the comparison honest enough that you can trust it. If you want to know how to compare Astrina live traffic with server logs, start by shrinking the problem before you start arguing with the numbers.
1. Confirm the server-log scope before you compare
Pick the exact log files first. A lot of teams mix production, staging, and preview traffic in one spreadsheet, then wonder why Astrina shows one pattern and the server shows another. Keep one site, one environment, and one traffic slice. That means naming the host, the app, and the log source in plain text before anything else.
If your server setup writes multiple files per day, note the rotation rule. If you have separate logs for the CDN edge and the origin server, choose one path and stick to it for the first pass. A clean scope makes the rest of the work smaller. A messy scope makes every mismatch look suspicious.
One practical example: compare only www.example.com on production, only page requests, and only the last 24 hours. Do not add API traffic, health checks, or admin URLs into the same comparison. Those are different animals.
2. Pick one exact time window and normalize the timestamps
Astrina live traffic works best when the window is exact. Server logs work best when the window is exact. Use the same start minute and the same end minute in both places, not “around noon” or “sometime after lunch.” Minute-level cutoff matters because one request on the boundary can move the count.
Use one timezone for both sides. If Astrina is showing UTC and your server logs are in local time, the comparison will fail before it starts. Convert the log timestamps once, then keep them in that format for the whole analysis. A 15-minute shift can create a fake spike. A 1-hour shift can make the data look broken.
Here is a small rule that saves time: never compare a rolling 5-minute Astrina window to a calendar-day log extract. That sounds obvious. People still do it. Choose one window, write it down, and use it everywhere.
3. Filter server logs down to human-page requests
Server logs contain everything, and that is the problem. Images, CSS, JavaScript bundles, favicon requests, prefetches, and crawler hits all sit beside page visits. Astrina is usually counting page visits, so the log must be narrowed to the same kind of request.
Filter out assets first. Then remove health checks, uptime probes, admin endpoints, and internal tools. If your load balancer calls /health every minute, those lines can distort the totals quickly. A page like /pricing should not be compared against 400 asset requests and three monitoring pings.
Bot filtering deserves attention too. Some bots look human for a few seconds, and some browsers look robotic because of their user agent. Do not rely on one signal. Use a combination of request path, user agent, and known internal IP ranges when you can. If your log includes a “bot” marker from a WAF or reverse proxy, keep that label. It helps later.
4. Map Astrina fields to log fields
Create a simple field map before you try to match records. Astrina may show a timestamp, page path, referrer, and session-like identifier. The log may show the raw request line, status code, user agent, and IP address. Those are not the same thing, and they should not be treated as if they were.
Build a two-column table on paper or in a sheet. On the left: Astrina field. On the right: log field. Timestamp maps to timestamp, path maps to request path, referrer maps to referrer header, and user agent maps to the user agent string. Session-like IDs are trickier, because the server log may not have one at all. That is not a failure. It is just a limit.
| Astrina field | Closest log field | Notes |
|---|---|---|
| Timestamp | Request time | Convert to one timezone first |
| Page path | URL path | Strip query strings for grouping |
| Referrer | Referer header | May be missing or shortened |
| User agent | User agent string | Good for bot checks |
Do not expect every Astrina field to have an equal log field. Some values are inferred. Some are modeled. Some are just not present in the server log at all. That is why the map matters: it tells you where direct comparison is possible and where it is only approximate.
5. Reconcile traffic by URL path, not by raw request line
Raw request lines are noisy. One visit to /docs may appear as /docs, /docs/, or /docs?utm_source=newsletter. If you compare those strings literally, you will split one page into three. Astrina may already normalize some of this. Your log probably does not.
Use canonical paths. Group all variants to the same page path before comparing counts. Strip query strings if they are not part of the page identity. Collapse trailing slashes where the site treats them as the same page. If redirects are involved, count the final destination, not the first hop.
This step often reveals a surprise. A page with 50 Astrina visits may show 63 log entries because 13 requests hit the non-canonical version first and then got redirected. That is not an error in the traffic. It is a path problem. Fix the grouping rule before you change the interpretation.
6. Check for mismatches caused by caching, proxies, or CDNs
Intermediary layers change what reaches the origin server. A CDN may answer the request before the origin ever sees it. A proxy may rewrite headers. A cache hit can serve a page to a user while leaving no matching origin line behind. That means Astrina can see a visit while the server log stays quiet.
The reverse can happen too. The origin log may record a request that Astrina never counts because the browser never finished loading the page, the script was blocked, or the request happened before the tracking code executed. A quick test page can make this obvious. Open the page in a browser, inspect the network tab, and see whether the tracking request fires before the page finishes loading.
If you run a CDN, check whether the log source is the edge or the origin. Those are different records. A 304 response, a cached HTML response, or a stale edge object can all produce false differences. This is where a short note in your comparison sheet saves an hour later.
For teams setting up the tracker for the first time, the installation path matters too. The agent setup is easier to verify if you follow the same deployment method used in production, which is why many teams keep the setup guide in their runbook beside the log export script.
7. Use a short discrepancy log to classify every gap
Do not leave mismatches as anonymous red cells. Write a discrepancy log with one line per gap. Give each line a category. Five categories are usually enough at the start: bot noise, missing log coverage, delayed ingestion, duplicate hits, and path normalization issue.
Here is a simple format: page path, Astrina count, log count, gap size, category, note. That note should mention one concrete cause, not a feeling. “CDN served cached HTML” is useful. “Looks weird” is not. If a gap repeats on three pages, that is a clue. If it appears once, that is still a clue, just a smaller one.
One team may find that a 12-request gap is caused by delayed log shipping. Another may discover that a browser extension blocks the tracking script on internal devices. A third may learn that the server writes duplicate lines on retry. The categories stop you from treating every mismatch as the same kind of failure.
If you want a deeper operational frame for this work, astrina for in-house product teams tracking can be a useful companion piece, especially when a traffic discrepancy turns out to be tied to a deploy.
8. Re-run the comparison on a small sample before scaling
Start with one page or one day. Not ten pages. Not a full month. One sample forces the rules to become explicit, which is good. If the sample includes /pricing only, you can inspect every mismatch by hand and see whether the method holds.
Look for stability before breadth. If the same filter, path rule, and time window produce the same answer twice, expand to a second page. If the numbers jump after you add another day, stop and check whether a deploy, a cache change, or a log rotation happened in the middle. A small sample is faster to correct than a large one.
There is a useful discipline here: change only one variable at a time. Move from one page to three pages, or from one day to two days, but not both at once. Otherwise you will not know which change broke the match. That sounds slow. It is faster than backtracking through 40 rows of bad assumptions.
Teams that are migrating from another analytics tool often see the same pattern during transition work. If that is your case, how to migrate from plausible is a practical reference to keep open while you verify the first sample against logs.
What to check when the numbers still do not line up
If the comparison still looks wrong after the eight steps above, inspect three things in order: the log source, the path rule, and the time window. Do not jump straight to the tracking script. A surprising number of “tracking bugs” are actually log extraction bugs. Another common cause is an overlooked redirect from /page to /page/.
Also check whether the browser session ends before the tracking request completes. Mobile connections are more fragile than desktop connections. A page can load visibly while the analytics call is cancelled. That leaves Astrina with fewer visits than the server log. The opposite can happen when the browser retries a request and the server counts both attempts.
One more detail: if your site has a maintenance page or maintenance mode, treat that traffic separately. A maintenance event changes both user behavior and log shape. If you need a companion reference for that situation, what to do when astrina uptime can help frame the incident before you compare it to the logs.
The strongest comparisons are small, documented, and repeatable. A clean scope, one time window, filtered page requests, and canonical paths will usually explain most of the gap. The remaining difference is where the useful work lives.
