Linux last Command: Check Login History

The Linux last command shows recent login sessions recorded on a machine:

last

It can tell you which account logged in, which terminal the session used, where a remote login came from, when it started, and when it ended. It also records useful system events such as reboots and shutdowns.

Use last when a user asks whether their account connected, a service stopped around a reboot, an SSH session dropped unexpectedly, or you need evidence for a ticket instead of “the server probably restarted sometime Tuesday.”

Quick last command reference

Goal	Command
Show recent sessions	`last`
Show the newest 10 records	`last -n 10`
Check one user	`last alex`
Show IP addresses instead of hostnames	`last -i`
Show full timestamps	`last -F`
Show records since a time	`last -s "2026-07-20 00:00:00"`
Show records until a time	`last -t "2026-07-21 00:00:00"`
Show reboot history	`last reboot`
Show shutdown history	`last shutdown`
Read a different history file	`last -f /path/to/wtmp`

Start with last -n 10. A short result is easier to read, easier to paste into a ticket, and less likely to bury the event you actually care about.

Read basic last output

Run:

last -n 5

Example output:

alex     pts/1        10.20.30.44     Fri Jul 24 08:42   still logged in
morgan   pts/0        10.20.30.18     Fri Jul 24 07:55 - 08:31  (00:36)
reboot   system boot  6.12.31-linux   Fri Jul 24 07:48   still running
alex     pts/2        10.20.30.44     Thu Jul 23 16:12 - 16:48  (00:36)
shutdown system down  6.12.31-linux   Thu Jul 23 17:03 - 07:48  (14:45)

Here is what the columns mean:

Part	Example	Meaning
Account or event	`alex`, `reboot`	User session or system event
Terminal	`pts/1`	Terminal associated with the session
Source or kernel	`10.20.30.44`	Remote source, hostname, or kernel version
Start time	`Fri Jul 24 08:42`	When the record began
End time	`08:31`	When the session ended
Duration	`(00:36)`	How long the session lasted
Current state	`still logged in`	No logout has been recorded yet

A pts/... terminal usually means an SSH or other pseudo-terminal session. A local graphical or console login may appear as tty... or with a display value such as :0.

The final line of normal output looks like this:

wtmp begins Mon Jul  6 09:11:20 2026

That is the oldest point covered by the current history file. It is not necessarily the day the server was installed.

Where last gets its data

On many distributions, last reads /var/log/wtmp, a binary log maintained by the login system. Newer systems may use a wtmpdb database instead. Do not open either one in a text editor and expect a useful result.

On a traditional wtmp system, check that the file exists:

ls -lh /var/log/wtmp

Then let last decode it:

last -n 10

History may be incomplete because login-accounting data can be rotated, cleared by an administrator, excluded from a minimal container image, or unavailable on some systems. A blank result does not prove nobody ever logged in. The final line may say either wtmp begins or wtmpdb begins, which tells you which backend supplied the result and how far its current history reaches.

Treat last as one evidence source. For a serious access investigation, compare it with SSH logs, systemd journal entries, identity-provider records, VPN logs, and whatever centralized logging your organization uses.

To find sessions for one account, put the username after the command:

last alex

Limit the output when you only need the newest records:

last -n 10 alex

This is useful for tickets such as:

“Was my account connected before the maintenance window?”
“Did the vendor actually log in?”
“Why did my SSH session disappear?”
“Has this disabled account appeared recently?”

Be careful with conclusions. A recorded login proves that a session was created for that account. It does not prove who was physically at the keyboard, what commands they ran, or whether the session was authorized.

If an account should have been disabled, verify its current status separately. Login history is not an access-control check.

Show IP addresses instead of resolved names

By default, last may show hostnames when they are available. Use -i to show numeric IP addresses:

last -i -n 10

Numeric addresses are often better for ticket notes because DNS can change and reverse lookups can be misleading.

Example:

morgan   pts/0        10.20.30.18     Fri Jul 24 07:55 - 08:31  (00:36)

Do not immediately declare an unfamiliar IP malicious. It may belong to a VPN pool, jump host, network address translation gateway, office connection, monitoring service, or cloud access layer. Check your network records before escalating.

The opposite mistake is also common: recognizing a familiar private IP and assuming the login is safe. An address identifies a network source, not a person.

Use full timestamps for investigations

Normal output saves space, but incident timelines need precision. Use -F for complete login and logout timestamps:

last -F -n 10

You might see:

morgan pts/0 10.20.30.18 Fri Jul 24 07:55:14 2026 - Fri Jul 24 08:31:02 2026  (00:35)

Now you can compare the session with an alert, deployment, failed backup, or service restart without guessing which year or minute was involved.

Before comparing systems, verify their clocks and time zones. Two correct logs can appear contradictory when one is in UTC and another is in local time. The timedatectl guide shows how to check the system clock, time zone, and synchronization state.

Filter records by date

Modern last implementations support date filters, though accepted time formats can vary slightly.

Show records since a date and time:

last -s "2026-07-20 00:00:00"

Limit a maintenance window:

last -s "2026-07-20 22:00:00" -t "2026-07-21 02:00:00"

Combine date filters with a username:

last -s "2026-07-23 00:00:00" alex

Options differ across distributions and versions. If a filter fails, check the local manual:

man last

That is faster than trying six copied commands from search results and deciding Linux is being difficult on purpose.

Check reboot and shutdown history

last records more than user sessions. Check reboots with:

last reboot

Check orderly shutdown records with:

last shutdown

This helps when a ticket says an application “randomly stopped” but the server rebooted three minutes earlier.

A useful sequence is:

last reboot -n 10
last shutdown -n 10
uptime -s

uptime -s reports when the current boot started. If it matches the newest reboot record, your timeline is becoming less mysterious.

Missing shutdown records can matter, but they are not automatic proof of a crash. Sudden power loss, forced resets, incomplete logging, rotated history, and some virtual-machine operations can all leave gaps. Follow up with:

journalctl --list-boots
journalctl -b -1 -e

The first command lists boots known to the systemd journal. The second shows the end of the previous boot, when that journal is available. Use the Linux log-reading guide if journalctl is still new to you.

Understand “still logged in” and “gone - no logout”

A record ending in still logged in means wtmp does not contain a matching logout yet. The session may really be active, so check current sessions:

who

The who command guide explains terminals, remote sources, and current-session checks.

You may also see:

gone - no logout

That means last found a login but no normal logout before the next relevant system event. Common causes include:

The machine rebooted or crashed.
The network connection dropped.
The SSH client was closed abruptly.
The session or terminal ended without a clean logout record.
The history file has gaps.

It does not automatically mean the account is currently connected, and it does not automatically mean an attacker killed the session. Compare it with who, reboot history, and logs from the same time.

Read an older rotated wtmp file

Log rotation may move older records to files such as /var/log/wtmp.1. If that file exists, read it with -f:

sudo last -f /var/log/wtmp.1 -n 20

First inspect available files:

ls -lh /var/log/wtmp*

Do not assume every system uses the same rotation names or retains the same amount of history. Retention is an operational policy, not a universal Linux constant.

Also do not copy history files into public ticket attachments without checking your organization’s rules. They can expose usernames, source addresses, login times, and operational patterns.

last is not the same as lastlog or shell history

Three similarly named tools answer different questions:

last shows a sequence of login sessions and system events from wtmp.
lastlog traditionally shows the most recent login recorded for each account.
Shell history, such as history, shows commands saved by a shell for the current user.

If someone asks, “When did this user last log in?” either last alex or an account-specific last-login tool may help.

If someone asks, “What command did I run before this one?” use shell history instead:

history | tail

If someone asks, “What did another administrator do during their session?” last cannot answer that. You need properly configured audit logs, sudo logs, shell auditing, or centralized session recording.

A practical help desk workflow

Suppose an overnight backup failed at 02:14 and the application owner suspects a reboot or maintenance session.

1. Confirm the machine and clock

hostname
timedatectl

Check that you are on the correct host and understand its time zone.

2. Check current uptime

uptime -s

If the machine booted at 02:10, the backup failure already has a strong lead.

3. Review reboot and shutdown records

last -F reboot -n 10
last -F shutdown -n 10

Look for an event near 02:14.

4. Review user sessions in the same window

last -F -s "2026-07-24 01:30:00" -t "2026-07-24 03:00:00"

Record relevant accounts, sources, and timestamps without claiming the login caused the failure.

5. Compare logs

journalctl --since "2026-07-24 01:30" --until "2026-07-24 03:00"

Now your ticket can say what the system recorded rather than assigning blame based on one line.

A solid note might be:

Host booted at 02:11 local time. last shows a reboot record at 02:11 and an admin VPN session from 01:58 to 02:19. The backup failed at 02:14. Reviewing change and journal records to confirm whether maintenance caused the interruption.

That is evidence. “Alex broke backups” is a meeting invitation.

Beginner mistakes to avoid

Treating last as live session truth

Use who for currently recorded sessions. last is historical and may contain unclosed records.

Assuming an IP address identifies a person

VPNs, jump boxes, shared workstations, and NAT make that unsafe. Correlate with identity and access records.

Forgetting log rotation

The current login-accounting database may cover only part of the period you need. Check its beginning line and any retained or rotated files.

Ignoring time zones

Write the time zone in incident notes. “02:14” is not precise when teams and systems span regions.

Expecting command history

last records sessions, not every command executed during them.

Reading absence as proof

No record can mean no session, but it can also mean missing, rotated, disabled, or incomplete accounting.

last is easy to type. The useful skill is building a careful timeline: confirm the host and clock, distinguish current sessions from historical ones, compare reboots with logins, and avoid accusing someone because their username appeared near an outage.

Practice Linux command-line troubleshooting in Shell Samurai so these checks feel normal before you need them during a real access or outage ticket.

FAQ

What does the Linux last command show?

It shows login sessions and selected system events recorded in wtmp, including usernames, terminals, remote sources, start and end times, durations, reboots, and shutdowns.

Run last username, such as last alex. Add -n 10 to limit the result or -F to show complete timestamps.

Why does last say still logged in when the user is gone?

The login record may not have received a matching logout because of a dropped connection, crash, reboot, or logging gap. Check current sessions with who and compare reboot history.

Does last show commands a user ran?

No. It shows sessions, not command activity. Use approved audit, sudo, shell, or centralized logging when command-level records are required.

Why is last empty?

The system may not maintain wtmp, the file may have been rotated or cleared, the environment may be a minimal container, or there may be no retained records. Check /var/log/wtmp* and your distribution’s login-accounting setup.