Rate Limits
Monitor active rate limits and clear rate limit counters during approved Edmissa admin troubleshooting.
Rate limits protect Edmissa by slowing repeated or unusually heavy requests. They help reduce risk from repeated sign-in attempts, password reset requests, API traffic, account creation, exports, and heavy reports.
The Rate Limits page is mainly a monitoring and admin troubleshooting page. It shows the configured limits, active usage, blocked identifiers, and reset actions. It is not a routine daily setup page.
What this guide helps you do
| Area | Use it for |
|---|---|
| Rate Limit Configurations | Review the visible limit, duration, block duration, and description for each protected area. |
| Active Rate Limits | Review current usage by endpoint and identifier. |
| Refresh | Load the latest monitor data immediately. |
| Cleanup | Remove expired rate limit entries. |
| Clear | Clear one active identifier when you have confirmed it is safe. |
| Clear All | Remove all rate limit entries during an approved urgent reset. |
Before you start
Prepare these details before clearing any limits:
| Item | Why it matters |
|---|---|
| Admin permission | You need permission to manage security settings. |
| Reason for review | Rate limits are security controls, so every reset should have a clear reason. |
| Identifier | Know which user, IP address, or integration is affected before clearing anything. |
| User impact | Clearing a limit can allow immediate retries. Make sure the activity is expected. |
| Timing | Avoid broad resets during active suspicious traffic. |
Use the narrowest reset that solves the problem. Prefer Clear for one identifier over Clear All.
Open Rate Limits
Use this path when you want to monitor active rate limits:
- Open Settings.
- Open Rate Limits.
- Confirm the page title is Rate Limit Monitor.
The direct route is /t/settings/rate-limits.
The page includes Refresh, Cleanup, and Clear All actions.
Review rate limit configurations
The Rate Limit Configurations table shows the current settings for each protected area.
| Column | Meaning |
|---|---|
| Endpoint | The protected area or action. |
| Limit | Number of requests allowed in the duration. |
| Duration | The time window for the limit. |
| Block Duration | How long the identifier can be blocked after exceeding the limit. |
| Description | What the limit protects. |
The visible configurations include:
| Endpoint | Limit | Duration | Block Duration | Protects |
|---|---|---|---|---|
login | 5 requests | 1 minute | 5 minutes | Login attempts per IP address. |
loginHourly | 20 requests | 1 hour | 1 hour | Login attempts per IP address over a longer window. |
passwordReset | 3 requests | 1 hour | 1 hour | Password reset requests per IP address. |
tokenRefresh | 10 requests | 1 minute | None shown | Token refresh requests per IP address. |
tokenRefreshHourly | 100 requests | 1 hour | None shown | Token refresh requests per IP address over a longer window. |
api | 100 requests | 1 minute | None shown | General API requests per authenticated user. |
apiHourly | 1000 requests | 1 hour | None shown | General API requests per authenticated user over a longer window. |
accountCreation | 3 requests | 1 hour | 2 hours | Account creation requests per IP address. |
dataExport | 5 requests | 1 day | None shown | Data export requests per authenticated user. |
heavyReports | 30 requests | 1 minute | None shown | Resource heavy report requests. |
heavyReportsHourly | 300 requests | 1 hour | None shown | Resource heavy report requests over a longer window. |
These limits are designed to protect normal use. Do not clear them simply because a user wants to repeat a blocked action many times.
Review active rate limits
The Active Rate Limits section appears when Edmissa has active rate limit data to show. Each endpoint can show:
| Field | What it means |
|---|---|
| Total Requests | Requests counted in the current rate limit data. |
| Blocked | Count of blocked entries. |
| Unique IPs | Number of unique identifiers shown for that endpoint. |
The table under each endpoint can show:
| Column | Meaning |
|---|---|
| Identifier | The user, IP address, or key being tracked. |
| Requests | Number of counted requests. |
| Status | Active or Blocked. |
| Usage | Percentage of the visible limit used. |
| Actions | Includes Clear when a single identifier can be reset. |
If the page shows No active rate limits found, there are no current entries to review.
Refresh and cleanup
The monitor refreshes automatically about every 10 seconds. Use Refresh when you need the latest view immediately.
Use Cleanup to remove expired entries from the monitor. Cleanup is useful after a busy period when old entries should no longer affect the visible list.
Clear one identifier
Use Clear when you have confirmed that one blocked identifier should be allowed to try again.
- Open Rate Limit Monitor.
- Find the endpoint related to the issue.
- Review the identifier, request count, status, and usage.
- Confirm the activity is expected and safe.
- Select Clear for that identifier.
- Ask the user or connected tool to retry the action.
- Refresh the page and confirm the activity looks normal.
Good reasons to clear one identifier include:
- A trusted user mistyped a password several times and is now blocked.
- A password reset was requested too often during a support call.
- A trusted integration made a short burst of API requests during testing.
- A data export was retried after a known user error.
If the same identifier becomes blocked again, investigate the cause instead of clearing it repeatedly.
Clear all rate limits
Use Clear All only for an approved urgent reset. It removes all current rate limit entries for all users and IPs.
When you select Clear All, Edmissa opens a confirmation dialog titled Clear All Rate Limits. The final action is Clear All Rate Limits.
Before using it:
- Confirm there is no active suspicious traffic.
- Confirm a narrower Clear action is not enough.
- Tell affected admins what you are about to reset.
- Use Clear All.
- Monitor the page after the reset.
- Review audit history or security logs if the reset was part of an incident.
Do not use Clear All as a normal support shortcut. It can temporarily reduce protection for the whole workspace.
Troubleshooting
| Issue | What to check |
|---|---|
| A user cannot sign in | Review login and loginHourly for the user's IP address. |
| Password reset is blocked | Review passwordReset for the user's IP address. |
| A connected tool receives 429 responses | Review api and apiHourly for the authenticated user or key. |
| Exports are blocked | Review dataExport for the authenticated user. |
| Reports are being throttled | Review heavyReports and heavyReportsHourly. |
| Many identifiers are blocked at once | Pause before clearing. Review whether the traffic is expected. |
If the same issue keeps returning, check the workflow that is creating the requests. A script, integration, browser retry, or repeated manual action may need to be corrected.
Recommended admin practice
Use a careful review habit for rate limits:
- Check which endpoint is affected.
- Identify the user, IP address, or connected tool.
- Confirm the activity is expected.
- Clear only the affected identifier when possible.
- Ask the user to retry once.
- Watch whether the same limit is hit again.
- Record broad resets so future admins understand what happened.
Rate limits are protective controls. Clearing them should solve a specific known problem, not hide repeated failed activity.
Related guides
| Guide | Use it for |
|---|---|
| Security and audit | Understand how rate limits fit with workspace protection. |
| Session Policy | Configure session behavior and extra checks for sensitive actions. |
| API Access | Manage tokens used by approved external tools and integrations. |
| Audit Logs | Review activity after sensitive support or security changes. |
| Users | Review affected user access, status, and support context. |