How to Measure Your Own Email Response Time

Your email response time is not what you think it is. Most people who estimate it — saying something like 'a couple of hours' — are recalling the threads where they replied quickly, not the Tuesdays when a supplier email sat until Friday or the meeting request that aged four days before they opened it. Your real number, pulled from your sent history, is usually worse than your felt sense of it.

That gap matters when you have made any commitment about reply speed — a personal SLA, a team norm, a service promise to clients. You cannot know whether you are keeping it without measuring it, and measuring it requires more than glancing at a few timestamps.

This guide covers three methods for pulling your actual response time from Gmail or Outlook, why median is the right number to track rather than average, and which threads to filter out before you calculate. The first measurement takes about thirty minutes.

What to exclude before you start measuring#

Before you pull any data, decide what response time you are actually measuring. Two definitions cause most of the confusion: first-reply time, meaning how quickly you respond to a message you have not touched yet, and full-thread resolution time, meaning how long a conversation runs from first contact to close. For personal-inbox purposes, first-reply time is the relevant figure — the question is how quickly someone who emailed you can expect to hear back.

Filter out threads that would corrupt the sample. Automated sends from your own address — calendar notifications, CRM sequences, out-of-office replies — carry your address in the From field but do not represent a human decision to respond. Mass emails you received — newsletters, promotional mail, billing receipts — are not messages where anyone expected a direct reply, so your silence on them is not latency worth measuring.

One further category is worth removing: replies you scheduled or drafted and later cancelled. Some mail tools log scheduled sends with the moment you drafted the reply, others with the moment it actually left your server, and a few record both. Mixing those timestamps in the same sample will make some threads look faster than they were and others look slower. If your export includes scheduled-send data, either normalize to the actual-sent timestamp or exclude the affected threads entirely.

What remains is the signal: a person or organization sent you a direct message and you chose to reply. The gap between those two timestamps is the response time you are trying to measure.

How to measure your email response time: three methods#

There is no built-in button in Gmail or Outlook that reports your personal median response time. You reach that number by one of three routes: exporting your mail data and calculating in a spreadsheet, sampling a date window using search, or using admin reporting tools if your organization runs Google Workspace or Microsoft 365.

1. 1

   Method 1: Export your mail and calculate in a spreadsheet

   In Gmail, open Google Takeout at takeout.google.com, select only Gmail, and export as MBOX. Filter the export for messages in your Sent folder that contain an In-Reply-To header — these are your replies rather than new threads you initiated. For each reply, find the corresponding received message and subtract the timestamps to get the gap in minutes or hours. Sort the list and take the median. In Outlook, use File > Open and Export > Import/Export to produce a PST, then open it in a local Outlook client or convert it with a free PST-to-MBOX utility before applying the same logic. Third-party tools such as EmailAnalytics or Polymail can automate this flow by connecting to your mailbox via OAuth and calculating the median without a manual export. A concrete example makes the process easier to picture: export three months of mail, discover 240 sent messages with an In-Reply-To header, then remove 30 automated sends and 40 threads you started yourself. That leaves 170 clean samples. Compute the gap for each — 12 minutes, 3 hours, 18 minutes, 2 days, and so on — then sort the list from shortest to longest. The value at position 85 in that sorted list is your median. If it reads 47 minutes, that is your typical inbound response time for the quarter, and the number you should hold yourself accountable to.

2. 2

   Method 2: Search-window sampling

   In Gmail, search from:me in:sent and restrict by date using the search tools panel or by adding after: and before: parameters. Filter visually for replies by looking for threads where the subject starts with Re: and the original sender is outside your domain. Open 30 to 50 threads at random and record the time gap for each. This is slower than an export but requires no data download. It works best as a sanity check — useful for confirming that your estimate is roughly right, not for computing a precise number. In Outlook, use Advanced Find under the Search tab to filter Sent Items by date range and spot-check threads by the same method.

3. 3

   Method 3: Admin reporting in Google Workspace or Microsoft 365

   If you have read access to Google Workspace admin reporting, the Admin Console under Reports and then Email shows aggregate send and receive volumes by user, but it does not expose individual reply latency. Microsoft 365 admin center offers similar aggregate views under Reports and then Email Activity. Microsoft Viva Insights adds per-user collaboration analytics including response time data, but it requires a separate license. Admin reporting is the right tool for team-level monitoring or identifying users with unusually high or low activity. For a personal baseline measurement, the export method gives cleaner and more granular data.

Gmail vs Outlook: where each method works#

The three methods work across both platforms but differ in the access they require and the manual effort they demand. The table below maps them out so you can choose the right starting point for your setup.

Median vs average: which number to track#

Both the mean and the median describe your response time in a single figure, but they answer different questions. The mean is the sum of all gaps divided by the count. The median is the midpoint: half your replies were faster, half were slower.

For email response time, the median is almost always the more useful figure. One missed message that sat for 72 hours shifts your weekly mean by several hours even if you answered every other email within thirty minutes. The mean penalises the outlier as heavily as it would if most of your mail ran slow. The median absorbs it: a single delayed reply cannot move the midpoint unless more than half the sample is also slow.

A concrete example: if 51 of your replies land between 10 and 45 minutes and 50 take between 1 and 72 hours, your mean might read 3.5 hours while your median stays under one hour. The mean signals a slow responder; the median gives the more accurate picture of your typical behavior.

A second scenario sharpens the case. Picture a support agent handling routine tickets who replies to 200 messages in a month. 180 of those replies land within 20 minutes; the remaining 20 sat over a long weekend and took roughly 60 hours each. The mean climbs past six hours — a number that would fail almost any published SLA and misrepresent the agent's actual pace. The median stays at roughly 15 minutes, which reflects operating reality: this is a fast responder with a batch of neglected weekend threads worth investigating as a separate incident rather than folding into the headline metric.

Use the median to track your personal SLA compliance. Use the mean only when you want to know total time load — for instance, when reporting team capacity and the cumulative hours matter more than the typical experience. If you report both, label them clearly: a stakeholder shown a single number will assume it means whatever they already expected, and the mean-vs-median distinction is exactly the kind of nuance that gets lost in a monthly summary.

What to do when the data does not cooperate#

Each method has a common failure mode. Knowing which one you are hitting saves debugging time.

Export is incomplete. Google Takeout exports mail incrementally and occasionally produces MBOX files with gaps. If your thread count looks unexpectedly low after import, run a second export or switch to an OAuth-based tool that reads your mailbox live. If your Outlook account is hosted on Exchange and PST export is disabled by your administrator, admin-level reporting is your only remaining option from within the organization's tooling.

Search-window sampling yields too few threads. A 30-day window captures 200 to 400 threads for an active inbox, but after filtering for replies and excluding automated sends, you may end up with 20 threads — not enough to trust the median. Extend the window to 90 days or more.

Admin reporting does not show individual response times. Most built-in tools — Google Workspace Reports, standard Microsoft 365 admin center — display aggregate activity: messages sent, received, and read. They do not expose the gap between an inbound message and your specific reply. For per-message response time, the export or a third-party OAuth tool is necessary.

Timestamps span multiple timezones. If you travel or your correspondents do, exported timestamps may mix UTC, your local device time, and the mail server's canonical time. A three-hour gap can look like a six-hour gap after a daylight-savings shift on either side, and a genuinely fast reply across an ocean can look sluggish because the received timestamp was recorded in a different zone from the sent timestamp. Convert every timestamp to a single reference zone — UTC is safest — before subtracting, and document which zone you used in whatever spreadsheet you keep the calculation in.

Threads have multiple recipients or multiple replies. When a message goes to a group and you were one of three people who replied, the received-to-sent gap is still yours to measure — but if you use the first reply from anyone in the group as the anchor, you will consistently understate your own latency. Anchor each calculation on the specific inbound message that had you as a direct recipient, and use only your own sent timestamp for the reply. If you replied more than once in the same thread, count only the first reply for response-time purposes; subsequent messages are part of the ongoing conversation, not the initial answer.

A faster way to track your response time#

Running the export-and-calculate process once gives you a baseline. Running it monthly to track whether you are improving means re-pulling the data, re-cleaning it, and recalculating — typically 30 to 60 minutes each cycle.

A tool that lives inside your inbox and tracks this continuously removes that overhead. AI Emaily's smart search and activity view surface reply patterns across connected mailboxes without a separate export. You can see which threads ran long, spot time-of-day patterns that account for most of the delay, and monitor your response time as a live view rather than a one-time exercise. For anyone managing a personal SLA or keeping an eye on response health across multiple accounts, this replaces the manual export cycle.

We build AI Emaily. You can try it with a 7-day free trial at aiemaily.com — no charge if you cancel before day seven. The full plan breakdown is at /pricing.