Start with three plain ideas: a system, a log, and an event.

A system is the Okta account your organization uses. A log is a written record, kept in the order things happened. An event is one single thing that happened, such as a person signing in, a password being changed, or an administrator editing a rule. The System Log is the running record of all the events in your Okta account.

Each event is stored as one entry. An entry says what happened, who did it, who or what it was done to, when, from where, and whether it worked. Because the entries are kept in order, you can read them like a diary, and ask questions such as “what happened to this account on Friday?” or “who edited this policy?”.

In short, the System Log answers three questions. What happened? Who or what caused it? And what was the result?

Three questions this guide answers

Everyday phrases and what they really mean

Identity teams use short phrases that confuse newcomers. When someone says “check the logs”, they usually mean open the System Log and search for the person or event involved. When they say “the event fired”, they mean Okta recorded that something happened. When they say “the actor”, they mean whoever or whatever caused the event. Knowing these three phrases makes most documentation much easier to read.

A few more words you will hear in meetings

Colleagues may say “audit trail” when they mean the ordered record of who did what, which is exactly what the System Log provides. They may say “telemetry” when they mean the stream of events that a system produces about itself. They may say “baseline” when they mean what normal looks like, such as the usual number of sign-ins per hour. And they may say “anomaly” when they mean something that does not fit the baseline.

None of these words is hard. Each names a piece of the picture you will see in this guide. When a new term appears, ask whether it is about the record itself, the way you search it, or the way you decide that something looks wrong. Placing the word usually reveals what it means.

Identity systems make thousands of quiet decisions every day. Without a record, nobody can explain them.

An Okta account may handle thousands of sign-ins, hundreds of policy decisions, and dozens of administrator changes every day. Most of them go well, and nobody notices. But when something goes wrong, people need to know exactly what happened. Without a record, every problem becomes an argument about memory, and every investigation becomes guesswork.

A good record solves several problems at once. It helps support staff fix a sign-in problem in minutes. It helps security teams see an attack while it is happening. It helps managers prove to auditors that rules are followed. And it helps administrators find out who changed what, and why a setting is different from last week.

What goes wrong without a good log

Why this matters even for small teams

Some teams believe logs are only for large security departments. In truth, the value begins the first time a single person asks “why was I locked out?”. A small company with ten users and one administrator faces the same questions, only on a smaller scale. Learning to read the log costs an afternoon. Fixing a problem without it can cost days.

A short vocabulary list makes the rest of this guide much easier to follow.

Logs have their own words. Most of them describe what is recorded, or how you look for it. The table below puts each term next to a simple picture.

Who, what, whom, and how

A good way to remember an event is to ask four small questions. Who did it? That is the actor. What did they do? That is the event type. To whom or to what? That is the target. And how did it go? That is the outcome. Almost every investigation is a conversation between these four questions.

Common misunderstandings

Every entry has the same basic parts. Learn them once and any entry becomes readable.

When you open one event in the System Log, you see a set of named fields. Each field answers one small question. Some fields are always present, and others appear only when they make sense for that kind of event. Knowing what each field means lets you read a log entry the way a doctor reads a chart.

Reading an entry in order

There are hundreds of event types. Thinking in families makes them manageable.

Each event has a type, usually written as a dotted name that starts with a general area and becomes more specific. For example, names that begin with “user.session” are about sessions, and names that begin with “policy” are about policies. You do not need to memorize hundreds of names. Learn the families, and look up the specific name when you need it.

A few famous examples

Why families help

When you are not sure what an event is called, start from the question. If it is about signing in, look in the session family. If it is about changing a rule, look in the policy family. If it is about someone leaving, look in the lifecycle family. This habit quickly turns a long list into a short path.

Knowing what normal looks like

A log is much easier to read when you know what a normal day looks like. Spend a little time, on a calm week, looking at the usual number of sign-ins, the usual failure rate, and the usual number of administrator changes. Write those numbers down. They become your baseline. When a day looks very different, such as ten times the usual failures, you notice at once, and you know where to start looking.

The baseline also protects you from false alarms. A rise in failed sign-ins on the first Monday after a holiday, or after a forced password change, is expected. A rise on a quiet Wednesday afternoon is not. Knowing the rhythm of your own company turns raw numbers into meaning.

Here is the full picture of where events come from and where they can go.

Events are created whenever something happens inside Okta. A person signs in, an administrator changes a setting, a policy is evaluated, or a program calls an interface. Each of these produces an event, which Okta writes into the System Log. From there, people can read it in the Admin Console, programs can fetch it through an interface, and copies can be streamed out to other tools.

flowchart LR
  subgraph Sources["Where events come from"]
    U["People signing in"]
    AD["Administrators changing settings"]
    PO["Policy decisions"]
    AP["Apps and API calls"]
    DI["Directory and integrations"]
  end
  subgraph OktaZone["Okta"]
    SL["System Log"]
  end
  subgraph Uses["Where events go"]
    CON["Admin Console search"]
    API["System Log API"]
    STR["Streaming to other tools"]
    HK["Event hooks and workflows"]
  end
  U --> SL
  AD --> SL
  PO --> SL
  AP --> SL
  DI --> SL
  SL --> CON
  SL --> API
  SL --> STR
  SL --> HK

The parts, one by one

Why one log for everything matters

Because all kinds of events land in one log, you can follow a story across areas. A sign-in, a policy decision, and an app access can all be seen side by side. This single view is what makes investigations quick, since you do not have to jump between separate tools to piece the story together.

The console page is where most people meet the log first. Here is how to use it well.

In the Admin Console, the System Log appears as a report page. At the top you choose a time range, such as the last hour or the last week. Below that, a search box and filters let you narrow the list. The main area shows events in order, newest first, each as one row. Clicking a row opens the full details of that event.

The parts of the page

A first investigation in four steps

Habits of a good log reader

Good readers of the System Log share a few quiet habits. They write down the question before they search, so that they do not wander. They keep the time window as small as is safe, so that results stay readable. They read the newest events first when solving a current problem, and the oldest first when reconstructing a long story. And they write notes as they go, separating what they saw from what they think it means.

These habits are easy to learn and pay off every time. A person who follows them can solve most support questions in a few minutes, and can hand over an investigation to a colleague without losing a single fact.

A good search finds the answer in seconds. A poor one buries it under thousands of rows.

There are two broad ways to search. The first is a keyword search, where you type words and Okta looks for them across the events. The second is a filter, where you state a precise condition, such as “the event type is this” or “the outcome is a failure”. Keywords are quick and forgiving. Filters are precise and powerful. Most good searches combine both.

Common things to search for

Narrowing step by step

Tips for better searching

The outcome is often the first thing to read. It tells you whether the event worked, and why not.

Every event carries an outcome. The outcome has a result, such as success or failure, and sometimes a reason that explains the result in words. For many problems, the outcome and the reason together are enough to tell you what went wrong, without reading anything else.

Common results

The value of the reason

A failure on its own is just a symptom. The reason is the diagnosis. A reason such as “invalid credentials” points to a wrong password. A reason about a locked account points to repeated failures. A reason about a policy points to a rule. Always read the reason before guessing at a cause.

Patterns beat single events

Three fields tell most of the human story: the person who acted, the place they acted from, and the thing they acted on.

The actor is whoever or whatever caused the event. It may be a person signing in, an administrator changing a rule, or an automated process such as an import. The client describes the doorway the request used: the type of device, the browser, and the network address and place. The target is the thing that was affected, such as an application, a group, a policy, or another user.

The three together

Why the client matters

The client tells you where an action really came from. A change made from an office address on a managed laptop looks routine. The same change made from an unfamiliar country on an unknown browser deserves a second look. Network address, place, device type, and browser together build a picture of the doorway.

Actors that are not people

One sign-in produces several events. Reading them in order tells the whole story.

When a person signs in to Okta, several things happen in a row. Okta checks the rules, collects the proofs, creates a session, and perhaps opens an application. Each step writes its own event. If you read them in order, you can see exactly where a sign-in succeeded, was challenged, or failed.

sequenceDiagram
  autonumber
  participant U as User
  participant O as Okta
  participant L as System Log
  U->>O: Try to sign in
  O->>L: Policy evaluation event
  O->>U: Ask for password and second proof
  U->>O: Provide the proofs
  O->>L: Authentication event with outcome
  O->>L: Session start event
  U->>O: Open an application
  O->>L: Application sign-on event

Reading the story

Where it goes wrong

When a sign-in behaves in a surprising way, the log can tell you which rule made the decision.

Policies are sets of rules, and Okta reads them in order. When it decides, it records an event that says which rule applied and what the decision was. These events are among the most useful in the whole log, because most surprises come from a rule matching when you did not expect it to.

What a policy event can show

A typical investigation

The log records every change in a person’s account life. These events are the backbone of access reviews.

Identity teams talk about three stages in a person’s time at a company. A joiner is a new hire. A mover is someone who changes role. A leaver is someone who departs. Each stage creates events, such as an account being created, activated, updated, suspended, or deactivated. Together they form the life story of an account.

The life of an account

Questions the lifecycle log answers

Administrators can change the rules for everyone. The log is how you keep that power accountable.

Administrators create policies, grant roles, edit applications, and change settings. Each of these actions writes an event, with the administrator as the actor and the changed object as the target. This record lets you answer the most common governance question: who changed this, and when?

Kinds of administrator events

Change review habits

Access is mostly granted through groups and application assignments. The log shows how each person got each access.

Most access in Okta flows through groups. A person joins a group, and the group is assigned to an application, and so the person gets the app. Each of these steps creates an event. Reading them in order reveals not only that a person has access, but how they got it, and who or what decided it.

Tracing how a person got an app

Why this matters for security

If people can add themselves to powerful groups, or if rules place people in groups by mistake, access spreads quietly. The assignment events are the early warning. A sudden burst of membership changes, especially into a sensitive group, is worth an immediate look.

The log is also a watchtower. Some events are raised precisely because they might be dangerous.

Beyond routine entries, Okta records events when it notices something that may be a threat. Examples include sign-in attempts from addresses with a bad reputation, large bursts of failed attempts, or users reporting suspicious requests. These events help security teams spot attacks early.

Common signs worth watching

A calm response routine

A single action can create many events. Correlation is the skill of tying them back together.

When one action touches many parts of the system, the log records many events. A single sign-in, for example, produces a policy event, proof events, a session event, and an application event. To read them as one story, you need a way to link them. Okta provides identifiers that tie related events together, so you can pull out only the events that belong to one action.

Ways to link events

A correlation routine

Stories that span days

Some stories are longer than one action. An attacker may probe over days, and a gradual permission creep may build over months. For these, correlate by person, by address, or by target over a wider time window. Longer stories need more careful reading, and often a spreadsheet or a separate tool to track the sequence.

Making stories easy to share

When you find the answer to a question, write it up in a few lines that someone else can follow. State the question, the time window, the search you used, and the key events with their times. Add the linking code, so that a colleague can pull the same events at once. A short, clear write-up saves the next person from repeating your work, and becomes a useful example for training.

Over time, a small library of such write-ups becomes a valuable teaching tool. New staff learn faster from real examples than from rules, and auditors see that the organization uses its log in a careful, repeatable way.

People read the log by hand. Programs read it through an interface. Here is the idea in simple terms.

An application programming interface, or API, is a way for one program to ask another for information. Okta offers an interface for the System Log. A program can ask it for events within a time range, matching certain conditions, and receive them in a structured form. This lets other tools collect, store, and analyze events without a person clicking through the console.

What a program can ask for

Why this interface matters

Things to plan for

The log does not keep events forever. If you need history, you must plan to keep it yourself.

Okta keeps System Log events for a limited time. The usual figure is around three months, but the exact period depends on your edition and may change, so confirm it in current documentation. After that, older events are no longer available in the console. Investigations and audits often need records from longer ago, so many organizations copy events to storage they control.

Why long-term storage matters

Ways to keep events

Storing events safely

Many organizations send the log to a central security tool, so it can be watched alongside everything else.

Security teams often use a system that gathers logs from many sources, such as networks, servers, and cloud services, and analyzes them together. These systems are commonly called SIEM tools, short for security information and event management. Sending Okta events into such a tool lets analysts see an identity event next to a network event, and spot attacks that no single source reveals.

flowchart LR
  OK["Okta System Log"] -->|"Stream or API collection"| PIPE["Collection pipeline"]
  PIPE --> STORE["Long-term storage"]
  PIPE --> SIEM["Security analysis tool"]
  NET["Network logs"] --> SIEM
  SRV["Server logs"] --> SIEM
  CLD["Cloud logs"] --> SIEM
  SIEM --> ALERT["Alerts and dashboards"]
  ALERT --> TEAM["Security and support teams"]

Two common ways in

Benefits of a central view

A log that nobody reads helps nobody. Alerts and dashboards bring the important events to people.

There are too many events to read by hand. The answer is to pick the few that matter, and have them find you. An alert is a notice sent when a chosen kind of event happens. A dashboard is a page of charts and counts that shows the health of the system at a glance. Okta also offers event hooks, which call another program as soon as a chosen event occurs.

Three ways to bring events to people

Events worth an alert

Dashboards that people use

Keep dashboards small and useful. A few clear charts are better than forty confusing ones. Good starting charts include sign-ins and failures over time, administrator changes per week, locked accounts per day, and the number of denials by rule. Show the trend and not only today’s number, since a sudden change is what draws the eye.

Instead of memorizing errors, learn a method: find the event, read the reason, and follow the story.

Almost every support question has the same first step: open the System Log, search for the person, and read what Okta recorded. The log usually points directly at the cause. The walkthroughs below show how the same method solves four common problems.

Walkthrough 1: A person cannot sign in

Walkthrough 2: A person is asked for a second proof unexpectedly

Walkthrough 3: A person lost access to an application

Walkthrough 4: Many people fail at once

When many people report the same problem at once, widen your search. Look at failures across all users in the same window, and group them by reason, application, or policy. A sudden cluster usually points at a shared cause, such as a policy edit, an expired certificate, or an outage in a connected system. Search for administrator changes just before the cluster began.

Training the whole team to read the log

The log is most valuable when many people can read it, not only one expert. Hold a short training session for support staff, administrators, and application owners. Walk through one real, anonymized case from start to finish: the question, the search, the key events, and the fix. Let each person try a search for themselves, and give them a one-page cheat sheet of the event types they will use most.

When more people can answer their own questions, the expert is freed for harder work, and problems are solved faster. A team that shares this skill also notices unusual patterns sooner, because more eyes are looking at the same record each week.

When something serious happens, the log is the main evidence. A calm, orderly method protects both the facts and the people.

An incident is an event that may harm the company, such as a suspected account takeover or an unexpected administrator change. In an incident, speed matters, but so does accuracy. A structured method keeps the team from missing steps or destroying evidence.

An investigation playbook

What the timeline should contain

When auditors visit, they ask for proof. The System Log is one of the best sources of it.

Compliance means following rules set by law, customers, or the company itself. Many frameworks for security and privacy expect companies to record who accessed systems, to control privileged access, and to show that leavers lose access in time. Governance is the set of habits and records that let you show these things clearly.

Evidence auditors often ask for

Governance habits that help

The log is a rich source of facts about people. Handling it respectfully is both right and practical.

Log events describe real people: when they sign in, from where, on what device, and what they do. That information is useful for security, but it is also personal. A fair design collects what it needs, limits who can read it, keeps it only as long as required, and explains its purpose. This approach is often called data minimization, and it lowers both risk and worry.

Who should see what

Good privacy habits

Retention and deletion

Do not keep personal facts longer than needed. Decide a retention period for each use, such as one year for security analysis and longer only where the law requires. When the period ends, delete the events from your own storage in a controlled way, and record that you did so.

The log is powerful, but it is not magic. Knowing its limits prevents wrong conclusions.

A log shows what Okta saw and recorded. It does not show everything that happened in the world. An application may do things after Okta handed over, and a device may be infected without any event in Okta. Reading the log well includes knowing what it cannot tell you.

Limits to remember

Common mistakes when reading

Keeping the log useful as the company grows

As a company adds people, applications, and integrations, the number of events grows quickly. A routine that worked for a hundred users may feel slow for ten thousand. Plan for growth by narrowing searches with good filters, moving heavy analysis to a central tool, and tuning alerts as volumes change. Review your retention, storage, and access choices each year, since the right answers shift as the organization changes.

Finally, remember that the log itself is part of your security story. Treat its settings, its exports, and its access rules with the same care you give to any other important control, and revisit them whenever the company changes in a way that adds new risk.

No design is perfect. Here is an honest scorecard for relying on the System Log.

Key trade-offs in plain words

A pattern is a proven way of solving a repeating problem. An anti-pattern is a popular mistake.

Patterns that work

Anti-patterns to avoid

A short field guide of habits that save time and avoid late-night incidents.

Best practices, in order of when you meet them

Mistakes that appear again and again

Here are four common situations where the System Log earns its place. The companies are fictional teaching examples.

Public facts that give context

Security standards and guidance around the world stress the value of keeping and reviewing access logs, because stolen credentials and misused privileges remain among the most common causes of breaches. Okta, founded in 2009, built its business on connecting people to applications securely, and its System Log is a central part of how customers see and prove what happens in their accounts. The detailed setups of specific customers are not public, so the stories above remain fictional.

Quick answers to the questions that come up most often.

The whole guide in one place.

The Okta System Log is the diary of your identity system. It records who did what, to whom, from where, and with what result, and it gives support teams, security analysts, administrators, and auditors the facts they need. Used well, it turns guesses into answers and quiet risks into quick fixes.

A mental model to carry with you

When any log question lands on your desk, sort it into one of four buckets. The first bucket is what: which event type and which outcome did you see? The second bucket is who: which actor, which client, and which target? The third bucket is when: where does the event sit in the story, and what came just before and after? The fourth bucket is why: which rule, reason, or change explains the result?

Most confusing situations turn out to be a mix-up between buckets. A strange denial is usually a why question, answered by the policy event. An unknown change is usually a who question, answered by the actor and client. A missing record is often a when question, caused by a window that is too narrow or an event older than the retention period. Naming the bucket first tells you which field to read and which search to run.

This model also helps when you explain the log to others. Managers care about when and why because they are about risk and proof. Support teams care about what and who because they explain complaints. Security teams care about all four, across many sources at once. A good identity architect speaks to all of them and keeps the runbooks written down.

A final word on the people behind the events

Behind every entry in the log is a real person trying to get on with their work, or a real attacker trying to get in. Logs that are searched well and protected well make life easier for the first group and harder for the second. Logs that are ignored or exposed do the opposite.

For the System Log, this means three promises. First, make it easy to find answers, with runbooks and practiced searches. Second, make it safe to keep, with limited access, protected storage, and sensible retention. Third, make it useful to act on, with a few well-tuned alerts that reach the right people in time.