> For the complete documentation index, see [llms.txt](https://docs.securepass.me/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.securepass.me/documentation/operations/troubleshooting-guide.md).
# Troubleshooting guide
Common symptoms and the first thing to check for each. These are starting points that resolve most problems quickly; anything that survives them needs the logs and, usually, support.
{% hint style="info" %}
Whatever the symptom, capture the **exact error text and the timestamp** before you start changing things. Both are what makes a log searchable, and both are the first thing support will ask for.
{% endhint %}
## Sign-in problems
The login page will not load.
This is infrastructure, not identity. Check the reverse proxy is running and check the SPAuth service is up and healthy. If the proxy is answering but SPAuth is not, users see an error from the proxy rather than a login page.
Credentials are rejected that should work.
Check the user's status before doubting the password — an account that is Inactive, Locked or Blocked refuses valid credentials. Then check the password against the current policy; a policy tightened after the password was set can invalidate it.
MFA is not working.
Which factor tells you where to look. OTP by SMS or email means the gateway — test it from **Configuration → Email & SMS**. Push means the app pairing. TOTP that rejects every code almost always means **clock skew**: time-based codes fail when the server and the phone disagree, and the failure looks exactly like a wrong code.
"Risk profile not found."
The user or the application has no risk profile assigned, or the one it references no longer exists. Check the assignment.
"Invalid redirect URI."
The URI the application sent does not match what is registered against it in SECUREpass. They must match exactly — scheme, host, port, path and trailing slash included.
## Application SSO problems
SAML assertions fail.
Two usual causes: a certificate or metadata mismatch between SECUREpass and the application, or clock skew between them. Check the certificate has not expired and that the metadata on both sides is current.
OIDC token validation errors.
Check the client configuration, the scopes being requested, and the signing keys. A key rotated on one side and not the other produces this.
Redirect loops.
The application signs in, bounces back, and starts again. Check the application's session and cookie handling and its SSO configuration — usually the application is not accepting the session it was just given.
## Privileged access problems
A target cannot be connected to.
Work outward: the connection profile, then the credentials, then network and firewall reachability. Most of these are reachability — the gateway must be able to reach the target on the port configured for it.
Session recording is not working.
Check the gateway and the recording storage configuration. Recording that silently fails is worse than recording that errors, so verify by playing a session back rather than by trusting the setting.
Credential checkout fails.
Check the vault configuration, and check whether an approval is pending. A checkout waiting on dual control looks like a failure to the user waiting for it.
## Sync, performance and database
A sync fails or returns nothing.
Check the connector's credentials and permissions first — expired credentials and insufficient read scope account for most of it. Then read the job logs under **Schedulers**, which record what each run did and where it stopped.
Sign-in is slow.
Tune the connection pool and the JVM heap, and check database load. Slow authentication is usually the database being saturated rather than the auth service being busy.
Database errors.
Verify connectivity, the schema, and the connection-pool limits. A pool exhausted under load produces errors that look like the database is down when it is not.
## Logs and health checks
Each service writes its own log and exposes a health endpoint. Between them they answer most questions: the health endpoint says whether a service is up, the log says what it did.
When you contact support, send the error text, the timestamp, the affected user or application, and the relevant service log around that time. A description without a timestamp usually costs a round trip.