# Weekday Okta sign-in security digest posted to Slack

> Every weekday morning, get one triaged summary of failed sign-ins, lockouts, denied multi-factor prompts, and logins from unfamiliar countries.

- Workflow type: agent
- Services: Okta, Slack
- Categories: Operations, Engineering
- Published: 2026-08-09

## What it does

- Reviews the last 24 hours of Okta sign-in activity every weekday morning, so nobody has to read the log by hand.
- Sorts what it finds into repeated failed sign-ins on one account, lockouts, denied or reset multi-factor prompts, and sign-ins from a country that person does not normally use.
- Names the people involved along with their department and account status, instead of showing a bare user ID.
- Posts one Slack message to your security channel with the serious items first, routine noise in a single line at the bottom, and a short all-clear on quiet days.

## What you'll need

- An Okta account with admin access, so the workflow can read your sign-in history and look up user details.
- A Slack workspace and the channel where security updates should land.
- A rough sense of what counts as unusual for your team, such as how many failed attempts in a row is worth flagging.

## Prompt

Every weekday at 8am, review my Okta sign-in security posture from the last 24 hours and post one triaged digest to my security channel in Slack.

Start with the Okta List System Log Events operation. Pull authentication events for a bounded window covering the period since the previous run, which is normally the last 24 hours ending at the moment the workflow runs. Always set both the since and until bounds explicitly in UTC. The Okta System Log retains about 90 days by default and queries beyond that require time bounds, so keep the window short and always bounded. Page through the results until there is no next page, so a noisy night does not get silently truncated.

Group what comes back into four buckets. First, failed sign-in spikes against a single account: the same user hitting roughly 5 or more failed sign-in attempts inside the window, and call it out loudly when those failures came from 3 or more distinct IP addresses or more than one country, because that is the shape of credential stuffing. Second, account lockouts. Third, MFA denials and factor resets, meaning denied or rejected multi-factor challenges and any factor reset or re-enrollment event. Fourth, sign-ins from a new country or an unusual location for that same user: for each user with a successful sign-in, compare the location against that user's own recent prior sign-ins in the same pull, look at roughly the last three sign-in locations, and flag it when the country differs. Also flag two sign-ins from different countries that are too close together in time to be real travel.

Cross-reference the repeat offenders with the Okta List Users operation so the digest names the person rather than a bare user id. For every user who lands in a flagged section, report their full name, their login or email, their department, and their current account status, such as active, suspended, locked out, or deactivated. If a flagged sign-in attempt targets a username with no matching user record, say so explicitly, because attempts against accounts that do not exist are themselves a credential stuffing signal.

Post exactly one Slack message using the Send a Message operation to my security channel. Lead with anything that looks like credential stuffing or account takeover, then the remaining flagged items in descending order of seriousness. Give each flagged person a short section with what happened, when it happened, the source IP addresses and locations involved, their department and account status, and a one line suggestion of what a human should check. Keep routine noise out of the body: ordinary one-off password typos and isolated failures that were followed by a successful sign-in from the user's usual location belong in a single short summary line at the bottom, for example "Routine: 14 isolated failed sign-ins across 11 users, each followed by a successful sign-in from a known location." Use Slack formatting with bold section headers and short lines, and keep it to one message rather than a thread.

If nothing crossed the thresholds, still post a brief all-clear that names the window reviewed and roughly how many events were checked, so the team knows the check ran rather than silently failing.

This workflow reads and reports only. Never suspend, deactivate, lock, unlock, reset a password, or reset a factor for any Okta user, no matter how suspicious the activity looks. Recommend the action in the message and leave the decision to a person.

## How to customize

- Change the timing. Run it every day including weekends, twice a day, or right before your team logs on.
- Adjust the thresholds, such as how many failed sign-ins against one account it takes before someone gets named in the digest.
- Send it somewhere else, like a private channel for the security team or a direct message to whoever is on call.

## Example output

Okta sign-in review, Thursday 8:00am, last 24 hours

1. Possible credential stuffing. Priya Raman (Finance, active)
41 failed sign-ins between 1:12am and 1:40am from 9 IP addresses across 3 countries, ending in a lockout. No successful sign-in. Suggest a password reset and a look at her active sessions.

2. Sign-in from a new country. Marcus Webb (Sales, active)
Successful sign-in from Lisbon, Portugal at 3:22am. His previous three sign-ins were all from Chicago. Worth confirming he is travelling.

3. Multi-factor denials. Dana Okafor (Support, locked out)
6 push approvals denied in 12 minutes, followed by a request to reset her authenticator. The account is currently locked out.

Routine: 14 isolated failed sign-ins across 11 people, each followed by a successful sign-in from their usual location. No action needed.

## FAQ

### Will this lock or suspend anyone automatically?

No. It only reads and reports. Every decision stays with your team, and the message tells you who to look at and why.

### How far back does it look?

The last 24 hours by default, ending at the moment it runs. Okta keeps roughly 90 days of sign-in history, so you can widen the window, but a short window keeps the digest fast and readable.

### What happens on a quiet day?

It still posts a short all-clear naming the period it reviewed, so your team can tell the difference between nothing happening and the check not running.

### Do I need a separate security tool to spot suspicious logins?

No. Everything comes from the sign-in history Okta already records. The workflow does the grouping and the comparison for you.

### Will it flood the channel on a busy morning?

No, it posts one message per run. Routine items are compressed into a single summary line, so only the things worth a human look get their own section.

Use this prompt in General Input: https://www.generalinput.com/prompts/weekday-okta-sign-in-security-digest-posted-to-slack