An edge case is a valid situation that sits outside the product’s normal or expected path. It may involve unusual input, missing data, a timing problem, a permission change or a system dependency failing at exactly the wrong moment.
Edge cases matter because the happy path is only one state of a product. The real experience also includes loading, empty, error, retry, partial success, expired sessions, permission limits and recovery.
Below are 20 practical edge case examples product, design, engineering and QA teams can use as a review checklist.
Quick take: use the examples below as prompts, then test them against one real product flow. If you want to map those states against your own product context, see Figr’s edge-case mapping workflow.
20 edge case examples in software
1. Empty required input
A user submits a form with a required field blank or filled only with spaces. The product should prevent submission and explain exactly what needs to be fixed.
2. Maximum-length input
A name, title or description is much longer than the team used in mockups. Check validation, truncation, wrapping and how the value behaves elsewhere in the product.
3. Unexpected characters
Users enter emoji, non-Latin characters, punctuation or pasted formatting. The system should store and display valid input safely without breaking layout or data handling.
4. Duplicate action
A user double-clicks Submit or retries an action after a slow response. The product should avoid creating duplicate orders, invites, payments or records.
5. Network drops during save
The user changes important data and connectivity disappears before the request completes. Show whether the change is saved, queued, retryable or lost.
6. Slow API response
A dependency takes much longer than usual. The interface needs a loading state, timeout behavior and a recovery path rather than an indefinite spinner.
7. Partial success
A multi-step request succeeds in one service and fails in another. For example, an account is created but the welcome email fails. The product should communicate the actual state and avoid repeating completed work.
8. User goes offline
The product is opened or used without connectivity. Decide what remains readable, what is disabled and what happens when the connection returns.
9. Session expires during a task
A user leaves a long form open, returns later and clicks Save after authentication has expired. Preserve their work where possible and guide them through re-authentication.
10. Account changes in another tab
The user signs out, switches workspace or changes account in a second tab. The first tab should not continue behaving as though the old permissions or identity are still valid.
11. Back button after a one-time action
A user completes checkout, payment or submission, then navigates backward. Make sure the UI does not allow an unsafe repeat of an already-completed operation.
12. Permission is revoked mid-session
A user is viewing or editing an object when an administrator removes access. The next action should reflect the new permission rather than relying on stale client state.
13. Role changes while the page is open
An admin becomes a viewer, or a member is promoted. Check which controls disappear, whether cached data remains visible and how the product communicates the change.
14. Expired invitation or magic link
A user opens an old invite, password-reset link or verification email. Give them a clear explanation and an obvious way to request a fresh link.
15. Zero-data state
A new account, workspace or report has no data. The empty state should help the user understand why it is empty and what action creates the first useful result.
16. Extremely large dataset
A table that looks fine with 20 rows may behave differently with 20,000. Check performance, pagination, filters, exports and bulk actions.
17. Time-zone boundary
An event crosses midnight or daylight-saving changes between creation and execution. Store and display time deliberately so users understand which timezone applies.
18. Leap day or invalid calendar date
Date logic should handle February 29, month-length differences and recurring schedules without silently shifting dates.
19. Concurrent editing
Two people update the same object at nearly the same time. Decide whether the product merges changes, warns about a conflict or uses last-write-wins behavior.
20. Resource limit reached
The user hits a seat, storage, API, project or usage limit in the middle of a workflow. Explain what is blocked, what remains safe, and what the user can do next.
A simple framework for finding edge cases
When reviewing a product flow, walk through these categories:
- Input: empty, invalid, very large, duplicated, pasted or unusual data.
- State: loading, empty, partial, stale, completed or conflicting.
- Permissions: no access, changed role, revoked access or different workspace.
- Network: offline, slow, timed out or dependency failure.
- Time: expired, delayed, timezone, recurring dates and calendar boundaries.
- Scale: zero records, thousands of records, maximum usage or rate limits.
- Concurrency: two tabs, two users or repeated actions.
- Recovery: what the user can do after something fails.
Use the categories as prompts, not as a guarantee that every possible edge case has been found. The product’s domain will introduce its own risks.
How to add edge cases to a PRD
Do not bury edge cases in a generic “error handling” sentence. For each important scenario, document:
- the trigger or condition;
- what the user sees;
- what happens to their data;
- what actions remain available;
- how they recover;
- what engineering or QA should verify.
For a fuller requirements structure, see our requirements document example or AI PRD generator guide.
How to turn edge cases into test cases
An edge case becomes useful to QA when it is observable. Convert the scenario into a test with a clear setup, action and expected outcome.
Example:
- Setup: user has an unsaved form and an expired session.
- Action: user clicks Save.
- Expected: the product asks the user to re-authenticate, preserves entered data and completes the save after successful login.
See how to create test cases for a deeper workflow.
Using AI to review product edge cases
AI can help teams generate questions around a flow, especially when it has enough context about the product, users and rules. It is most useful as a review partner: provide the actual flow and ask what states, permissions, failures and recovery paths are not represented.
Figr can help product teams reason across product context, flows and screen states before implementation. The output should still be reviewed by the people who understand the domain, system constraints and real user behavior.
Map the edge cases in your own flow or try Figr free.
Edge case review checklist
- What if required data is missing?
- What if the request is repeated?
- What if the network is slow or offline?
- What if only part of the action succeeds?
- What if the user’s session or permission changes?
- What if there is no data?
- What if there is far more data than expected?
- What if two users edit at the same time?
- What if a date, invite or token expires?
- What does recovery look like after failure?
FAQ
What is an edge case in software?
An edge case is a valid but less common condition that occurs outside the normal path, often at a boundary involving input, state, timing, permissions, connectivity or scale.
What is the difference between an edge case and an error?
An edge case is the condition. An error is one possible result if the product does not handle that condition correctly. A well-designed product can support an edge case without producing an error.
Who should identify edge cases?
Product, design, engineering and QA should all contribute. Each function sees a different class of risk, which is why edge-case review is most effective before implementation rather than at the end of testing.
Is there a free version of Figr?
Yes. Figr has a free tier for testing edge-case and flow-mapping workflows before moving to a paid plan.
Pick one important flow this week and review it against the checklist above. The goal is not to predict every unusual behavior. It is to make the highest-impact hidden states visible while they are still inexpensive to change.