nginx, Apache, IISTurn Web Server Logs into queryable tables.
Your access log is already a table — status codes, response times, client IPs, paths and user agents, one row per request. Point the agent at the log folder and query it, rotations and .gz archives included.
Use the results in Excel, Google Sheets, AI tools and your apps through the Database REST API.
Every connector type is on Free. Start with 2 data sources and 1 agent.
Read, organize and query on your machine.
Read-only queries · outbound connectionSource files stay in place. Your tools receive query results.
Query Streams turns the access logs nginx, Apache, Caddy and Microsoft IIS already write into live SQL tables readable from Microsoft Excel, Google Sheets, AI assistants over MCP, the REST API and Power BI. The formats have been stable for decades, so the profiles pin them exactly: status code, response time, client IP, path, referrer and user agent all arrive as typed columns. Rotated files and their .gz archives are part of the same table. No log shipper, no agent on the edge, and nothing uploaded - only query results leave your network.
- nginx, Apache, Caddy and IIS
- Rotations and .gz included
- No log shipper in the middle
Connect Web Server Logs with the right settings.
Keep the connection on the Network Agent. These are the details specific to Web Server Logs.
- Folder
- The server's log directory, or a folder logs are collected to - local disk or a network share typed as \\server\share (never a mapped drive letter; on Linux or a Mac, mounted first); subfolders included
- Servers
- nginx, Apache HTTP Server, Caddy and Microsoft IIS
- Format
- Pinned by the profile - combined and common for nginx and Apache, JSON lines for Caddy, the #Fields header directive for IIS
- Rotation
- Ten named rotation patterns plus plain unrotated files; compressed archives are read in place
- Unmatched lines
- Kept verbatim in events_raw_lines, never dropped
- Credentials
- None - there is no server to log into; the agent reads the files in place
- SQL dialect
- DuckDB - standard SQL, nothing web-specific to learn
This is not a log shipper. There is no daemon forwarding lines to a cloud index and no per-gigabyte ingest bill: the agent reads the files where they already are, keeps the parsed rows in an encrypted store on the same machine, and answers queries from it. Turning the connector off leaves your logs exactly as they were.
Built for how Web Server Logs works.
What comes out
- One row per request, with the timestamp, method, path, status code, bytes, referrer, user agent and client IP as real typed columns rather than one long string.
- Response time where the format carries it, so "slowest endpoints yesterday" is a query rather than an exercise in awk.
- _source_file names the file each row came from, which means per-host and per-vhost comparisons come free when you point the connector at a collected folder.
- Compressed archives are read in place - a folder holding thirty days of .gz is thirty days of queryable history, not thirty files to unzip.
-- Slowest paths in the last day, 5xx first
SELECT path, status, COUNT(*) AS hits, AVG(request_time) AS avg_s
FROM fileset.events
WHERE status >= 500
GROUP BY path, status
ORDER BY hits DESCAccess logs and error logs are different files
The access log records requests; the error log records what the server complained about, in a different format entirely. Both are supported and both become tables, but they are separate profiles rather than one connector guessing which file is which - point the connector at the folder and choose what you are reading.
The formats and behavior, in detail.
Open the reference you need for Web Server Logs.
A log folder becomes a table you can group and join.
A log folder becomes a table you can group and join.
Query Streams reads the files your web server already writes, pins the format, and gives you typed columns. No agent on the server, no shipping pipeline, no index to maintain — and a line the parser cannot read is kept as a row with a reason rather than silently dropped.
access.logCaddy
access.log.2.gznginx
u_ex260909.logIISRotations, compressed archives and re-read files — handled
SELECT path,
count(*) AS hits,
round(avg(duration_seconds) * 1000) AS ms
FROM fileset.events
WHERE status >= 500
GROUP BY path
ORDER BY hits DESCJoin it to your application database in the same query
Files your server already writes, now a table you can report on
Four servers, four formats, no configuration
Four servers, four formats, no configuration
Each card names the exact files Query Streams reads on that server and where they live. You do not change your logging config to make this work — the default format is the supported one.
Supported web server logs
4 formats · 4 servers
nginxAccess and error
access.logthe default combined formaterror.loglevel, pid, connection and message- Usually
/var/log/nginx - Appends; numbered rotations followed
Apache HTTP ServerAccess
access_logcombined and common formats- One parser covers Apache and nginx — the access format is the same
/var/log/apache2, orhttpdon RHEL- Appends; numbered rotations followed
CaddyCaddy 2 JSON
access.logone JSON object per request- TLS server name, version and session resumption included
- Response duration to the microsecond
- Rolls to
access-<timestamp>.log.gz; each member read once
Microsoft IISW3C extended
u_ex*.logW3C extended format- The
#Fields:header decides the columns, so your field selection is followed C:\inetpub\logs\LogFiles\W3SVC<site>- A new dated file per day, never renamed
New web server and proxy log formats are added with each Agent release. Because Agents keep themselves up to date, a format added later shows up in your connector without anyone touching a server.
Access logs from every edge, read where they land
Access logs from every edge, read where they land
A request does not always hit the same continent twice. Your edge sits in one region, your origin in another, and something older still runs in the office. Each location runs a Network Agent that reads the log files where they land and dials out to Query Streams. As far as your firewall is concerned that is an ordinary outbound connection — nothing to open, no VPN to build, and no log shipper to keep alive.
.gz archives
dials out
Three outbound connections, one place to query them — no inbound port, no VPN, no firewall change
One Agent per location
An Agent covers a whole location rather than a single log file, and within one location a folder tree of many hosts is a single connector — every row carries its site. The Free plan runs a single Agent and paid plans run more.
1 region = 1 Agent = many hosts
Nothing to open
The Agent makes one encrypted outbound connection, and the request out and the rows back both travel over it. No inbound port, no VPN, no firewall change to go and ask for — and nothing forwarding your logs to a third party in between.
one connection, both directions
One query across regions
Every source in a federated query names its own Agent, so a single statement can put the edge in one region beside the origin in another, or join either of them to your application database. Included on Business and Enterprise.
2 regions → 1 result set
They keep themselves current
Agents update themselves, so a log format added in a later release reaches every region without a deploy of your own. That is what makes the wall above a starting point rather than a fixed list.
new formats arrive with the Agent
Rotation is why this is not just a CSV import
Rotation is why this is not just a CSV import
Web logs do not sit still. They get rotated, renamed, compressed and re-created underneath you. Handling that correctly — without gaps and without counting a line twice — is most of the work.
Numbered rotations
The classic logrotate shuffle: today’s file keeps its name and yesterday’s shifts down a number. Query Streams follows the content, not the name.
access.log → access.log.1 → access.log.2.gz
Dated filenames
IIS never renames anything — it opens a new file each day with the date in the name. Old files stay exactly as they were, so they are read once and left alone.
u_ex260909.log · u_ex260910.log
Compressed archives
A rotated log usually ends up gzipped. Query Streams reads .gz members in place — you do not have to decompress anything or move it somewhere else first.
access-2026-09-08T03-00-00.000.log.gz
Nothing counted twice
Each file is fingerprinted by its first 4 KB, so a renamed file is recognised as the same file. A rolling duplicate window catches the overlap when a writer replays the tail.
4 KB prefix hash · 20,000-record window
The columns you actually get
The columns you actually get
Not a blob of text with a timestamp beside it. Each format is parsed into typed columns you can filter, group and aggregate on directly.
Every row also carries event_time and site, so one query can span several hosts and the file it came from is never in doubt.
What we deliberately do not read
What we deliberately do not read
A production access log carries more than you might want in a reporting table. Caddy’s JSON format records full request and response header maps, and those routinely contain session cookies and bearer tokens. The Caddy profile excludes request.headers and resp_headers by declaration — not by a filter you have to remember to switch on, and not after the fact. Those fields are never parsed, so they never reach a table, an export or a spreadsheet.
The rest of the design follows the same principle. The Agent connects outbound and reads files; nothing is installed on the web server, nothing is written back to it, and access is read-only.
From connection to useful results.
- Install the Network Agent where it can see the log folder - the web server itself, or a share the logs are collected to.
- Point the connector at that folder and pick the profile: nginx or Apache combined and common, Caddy's JSON lines, or IIS's W3C format.
- The profile pins the layout, so the columns are named and typed on the first sync - there is nothing to describe and nothing to sample.
- Rotation is understood. Yesterday's access.log.1 and last week's .gz are the same table as today's live file, and only new bytes are re-read.
- Query it. Slowest paths, 5xx by hour, top clients, bot traffic - ordinary SQL across every server you point it at.
Put your Web Server Logs results to work.
One connection serves your spreadsheets, apps and AI tools. Share permission to run a saved query; recipients see the allowed results, with the SQL and source login hidden.
For your team, vendors and partners
Pull live Web Server Logs results straight into a worksheet and refresh them on demand — desktop Excel, Excel Online, Microsoft 365.
Explore ExcelRun a saved Web Server Logs query from the sidebar and drop the rows into the sheet. Shared collaborators can refresh it themselves.
Explore Google SheetsAsk a question in plain English. Nova already knows your Web Server Logs tables, writes and runs the SQL, explains the answer and charts it — no query to write, no credentials to hand over.
How Nova worksShare a live Web Server Logs result with anyone — a colleague, a vendor, a partner — as a bookmarkable grid that re-runs fresh when opened, on a phone, a tablet or a desktop. They see the results, never the SQL or the files.
How the Data Viewer worksFor apps and systems
Publish a Web Server Logs query as an authenticated JSON endpoint any application can call, with an OpenAPI 3.1 spec and ready-made Postman, Insomnia and Hoppscotch collections. No database port is opened.
Explore REST APIPaste the generated Power Query M into the Power BI Advanced Editor and the report reads live Web Server Logs results over HTTPS — no ODBC driver, no database port opened.
Explore Power BISync Web Server Logs rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.
Explore AirtableFeed a Baserow table from Web Server Logs over the REST endpoint — self-hosted or Baserow cloud.
Explore BaserowKeep a SeaTable base current with Web Server Logs data without exporting a file or exposing the database.
Explore SeaTablePush Web Server Logs results into a Smartsheet grid so plans and reports read from the source system, not last week's export.
Explore SmartsheetBack an Anvil Python app with Web Server Logs through the REST endpoint instead of embedding database credentials in the app.
Explore AnvilFor AI tools
Give an AI assistant read-only access to Web Server Logs with the schema it needs to write correct SQL — no credentials in the chat.
Explore MCPDelivered to people
Put a Web Server Logs query on a schedule and have the rows delivered to Slack, Discord, email or a signed webhook — or hold the message until a row count, threshold or percentage change crosses the line you set.
How alerts and reports workJoin Web Server Logs to the rest of your data.
Bring databases, business APIs, files and logs into one read-only query. Every connector supports Federated Queries.
Name the connections and tables. Query Streams handles the source queries and combines the results.
Explore Federated Queries-- nothing copied, nothing merged, nothing scheduled
SELECT c.region, COUNT(*) AS orders, SUM(i.amount_due) AS invoiced
FROM weblogs.fileset.orders1 f
JOIN pg_crm.public.customers2 c ON c.id = f.customer_id
JOIN billing.stripe.invoices3 i ON i.customer = c.stripe_id
GROUP BY c.region
ORDER BY invoiced DESC;Use your own connection, schema, table and column names.
Shared across the connector family.
Every log connector also gives you
- events — one row per parsed line, with the timestamp, the fields the grammar named, and _source_file naming the file it came from.
- events_raw_lines — lines the grammar did not match, kept verbatim rather than dropped, so a format you did not anticipate is a question you can still answer.
- files_current and files_events — the live inventory and the audit trail: what appeared, what rotated, what vanished, and anything held back, with the filename and the reason.
- Rotation is understood, not worked around — ten named rotation patterns plus plain unrotated files, so yesterday's log and its compressed archive are the same table as today's.
Good to know
- Read-only, enforced — one statement at a time, SELECT and friends only. Your logs are never written, moved, rotated or truncated by us.
- Nothing is uploaded — lines are parsed and cached, encrypted, on your own machine beside the agent. Only the result of a query leaves your network.
- Only new bytes are read — the agent resumes where it left off in each file rather than re-reading it, so a busy log does not cost more every day.
- The SQL dialect is DuckDB — the same SQL you would write against any other connector.
Explore related connectors.
File System
CSV Folder
Parquet Folder
Excel Folder
SQLite Folder
JSONL Folder
Multi-record CSV
Machine LogsQuestions about Web Server Logs
Where can I use Web Server Logs query results?
Use Web Server Logs results in Excel, Google Sheets, the Data Viewer, your apps through the Database REST API, and AI tools through MCP or Nova. Saved results also feed supported Automation destinations, reports and alerts. Destination availability and allowances depend on your plan.
Do I need to open an inbound port for Web Server Logs?
No. Install the Network Agent on a machine that can reach Web Server Logs. The agent connects outward to Query Streams; no inbound port or VPN is needed. Your source must still allow the agent machine to connect under its own access rules.
Are my Web Server Logs files uploaded?
The Network Agent reads files where they are and keeps its cache on the agent machine. Source files are not uploaded, moved or rewritten. Only requested query results leave your network over the outbound encrypted connection.
What do I need to connect Web Server Logs?
Folder: The server's log directory, or a folder logs are collected to - local disk or a network share typed as \\server\share (never a mapped drive letter; on Linux or a Mac, mounted first); subfolders included. Servers: nginx, Apache HTTP Server, Caddy and Microsoft IIS. Format: Pinned by the profile - combined and common for nginx and Apache, JSON lines for Caddy, the #Fields header directive for IIS. Rotation: Ten named rotation patterns plus plain unrotated files; compressed archives are read in place
Can I join Web Server Logs to other connected sources?
Yes. Federated Queries support every connector type, including databases, business APIs, files and logs. Name the connections and tables in one read-only query. Query Streams translates the source portions as needed and combines their results. See how Federated Queries work.
Do I have to change my logging configuration?
No. Each supported format is the default one for that server: the combined access log for nginx and Apache, the JSON access log for Caddy 2, and W3C extended for IIS. If you have never touched your log format, you already have a supported one.
IIS is the flexible case, and it is handled properly — the #Fields: directive at the top of a W3C file names its columns, so whichever fields you selected in IIS Manager are the columns you get.
Is this real-time?
It is on-demand rather than streaming. Query Streams reads the files as they are on disk when you run the query, so new requests appear as your server writes them and the file is picked up — not on a fixed nightly schedule, but not a live tail either.
If you need sub-second alerting on a request as it happens, a log pipeline is the right tool. If you want to ask a question of the last few weeks of traffic and get an answer in a spreadsheet, this is considerably less machinery.
What happens to rotated and compressed logs?
They are read. Query Streams understands the three rotation styles these servers use — logrotate’s numbered shuffle, IIS’s new-dated-file-per-day, and Caddy’s timestamped roll — and reads .gz archives in place without you decompressing them.
Files are matched by a hash of their first 4 KB rather than by name, so a rotated file is recognised as the one already seen. That is what stops a rotation from either losing a day or double-counting one.
My logs are on several servers. Can I query them together?
Yes. Every row carries a site column, so one query can span hosts and group by whichever you care about. You can deploy an Agent per environment or per region, and they all present their folders in the same list.
Because it is ordinary SQL, you can go further and join request logs to a real database — matching a spike in 500s against a deployment table, or slow checkout requests against the orders they belong to.
Does it read cookies or authorization headers?
No. Caddy’s JSON format is the only one of the four that records header maps at all, and the profile excludes request.headers and resp_headers by declaration, so they are never parsed into a column. The combined, error and W3C formats do not contain headers to begin with.
Client IP addresses and user agents are parsed, because they are the point of an access log — treat the resulting table with the same care as the log file it came from.
What about a line the parser cannot read?
It is kept, not dropped. A line that does not match the pinned format is retained as a raw row with a reason attached, so a malformed entry or an unexpected format change shows up as something you can see and query rather than as a silent gap in your numbers.
Put Web Server Logs where the work happens.
Start with Free: every connector type, 2 data sources and 1 Network Agent. Add plan allowances as your needs grow.
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish