Store Health Issues: What They Mean and What to Do Next

You open Bonesaw and see a yellow warning badge next to one of your stores. Or maybe two. Or maybe five. Some say "Timeout," one says "Traffic Challenge," another says "Server Error." Your instinct is either to panic or to ignore everything and hope it resolves itself.

Neither is the right move. Most store-health issues are temporary noise that clears on its own. A few are real problems that need your attention. The skill is telling which is which, and this guide walks you through exactly how to do that.

This is not about why monitoring sometimes produces false signals (the false down signals guide covers that). This is about what to do when Bonesaw surfaces an issue, how to read the severity, and how to decide your next step.

Business Signals vs Monitoring Issues

Before diving into issue types, it helps to understand that Bonesaw tracks two fundamentally different kinds of unusual activity:

Business signals are changes in what a store sells or how it operates. A competitor drops prices, launches new products, removes a product line, or changes their tech stack. These are the signals you monitor competitors for. They show up in your activity feed, anomaly dashboard, and weekly report.

Monitoring issues are problems with the act of monitoring itself. The store returned an error, blocked the request, timed out, or became unreachable. These do not tell you anything about the store's business decisions. They tell you that something about the monitoring connection needs attention.

The Issues Center deals exclusively with monitoring issues. If you are looking for business intelligence, you want the activity feed or anomalies dashboard. If you are looking at a yellow or red badge on a store, you are in monitoring-issue territory.

Where Issues Appear

Bonesaw surfaces health issues in several places so you catch them regardless of how you use the product:

Dashboard health summary. The top of your dashboard shows a breakdown of store health across your watched set: how many are OK, how many have warnings, how many are down, and how many are blocked or unscanned. If everything is green, you can move on. If not, click through to investigate.

Issues Center. The dedicated issues page at /app/issues shows every active issue across all your stores, grouped by type and severity. This is where you do triage.

Store detail page. Each store's detail view shows its current scan status, last successful check, fail count, and any active issues. Useful when you are investigating a specific store.

Weekly report. Your weekly report includes an issues summary with counts by type and a note about how many were auto-snoozed. This catches issues you might miss between logins.

The Three Severity Levels

Every issue gets one of three severity levels. Understanding these saves you from treating everything as equally urgent.

Blocked (red/amber). The store is actively restricting monitoring access. This includes stores that serve challenge pages (Cloudflare, CAPTCHA) and stores that return 403 or 429 responses. The store is almost certainly online and functioning for its customers. Your monitoring is just being filtered. This is the most common severity level and the least urgent from a business perspective.

Down (red). The store appears genuinely unreachable or broken. Timeouts, DNS failures, TLS errors, and server errors all start as warnings but escalate to "down" after three consecutive failures. When you see this severity, the store may actually be experiencing problems.

Warning (yellow). The first occurrence of a transient issue. A single timeout, a server error, or a DNS hiccup. Most warnings self-resolve within one or two scan cycles. They only escalate to "down" if they persist.

The general rule: blocked issues are about access, not availability. Down issues are about availability. Warnings are candidates that have not yet proven they are real problems.

Issue Types and What They Usually Mean

Bonesaw classifies issues into nine types, but you can think of them in three practical groups.

Access Restrictions

These issues mean the store is online but restricting automated traffic. They are the most common and least urgent category.

Blocked. The store returned a 403 (forbidden) or 429 (too many requests). This usually means the store's firewall or rate limiter flagged the monitoring request. The store is working fine for shoppers. Your monitoring is just being filtered. Action: snooze and wait. Most blocks are temporary. If it persists for more than a week, the store may have tightened its traffic policies permanently.

Traffic Challenge. The store is serving a verification page (Cloudflare challenge, CAPTCHA, or similar interstitial). Like blocks, this means the store is operational but filtering automated traffic. Action: snooze. These typically rotate and resolve within a few days.

Robots Denied. The store's robots.txt file disallows access to the pages Bonesaw checks. This is an intentional configuration by the store operator. Action: snooze. This rarely changes unless the store redesigns their site.

JS Required. The store's product pages require JavaScript to render content, and the initial page load returned no useful product data. Action: snooze. Bonesaw handles most JavaScript-rendered stores, but some configurations require special handling.

Connection and Server Problems

These issues suggest something may be wrong with the store itself or the network path to it. They start as warnings and escalate to "down" after three consecutive failures.

Timeout. The request took too long and was abandoned. A single timeout is meaningless. Two in a row is worth noting. Three or more in a row suggests the store is experiencing performance problems or is genuinely struggling. Action: if the fail count is under three, wait. If it hits three or more, check the store manually. If the store loads fine in your browser, the timeout is likely network-path-specific and will resolve.

DNS / TLS Error. DNS resolution failed, or the TLS handshake could not complete. DNS failures can mean the store's domain expired, their DNS provider had an issue, or there was a transient resolution problem. TLS failures can mean an expired certificate or a configuration change. Action: if this persists beyond two scan cycles, check the store. An expired certificate is a real operational issue the store owner may not realize they have.

Server Error. The store returned a 5xx status code (500, 502, 503, etc.). The store's server is responding but returning errors. A single 5xx is common during deployments or high-traffic periods. Persistent 5xx responses suggest the store is having real infrastructure problems. Action: wait for one cycle. If it escalates to "down" status (three consecutive failures), check the store manually.

Not Found. The store URL returned a 404 or 410. Either the monitored URL changed, the store reorganized their site, or the specific page was removed. Action: check the store URL. If the store moved to a new domain or restructured their URLs, you may need to update the monitored URL.

Unknown

Unknown Error. The scan failed but the error did not match any recognized pattern. This is the catch-all bucket. It can be anything from an unusual server response to a network issue. Action: treat it like a transient error. Wait for one cycle. If it persists and escalates, investigate the store manually.

The First-Pass Triage Checklist

When you see issues in your dashboard, run through this quick flow:

Step 1: Check the severity breakdown. If everything is "blocked" severity, your stores are fine. The monitoring is being filtered, not the stores going down. Move on unless you have been blocked for more than a week.

Step 2: Look for "down" severity issues. These are the ones that might need action. Check the fail count. A fail count of 3 means the issue just escalated. A fail count of 10 means it has been going on for a while.

Step 3: Cross-reference with what you see. For any "down" store, open it in your browser. Does it load? If yes, the issue is monitoring-specific and will likely self-resolve. If no, you are looking at a genuine outage.

Step 4: Snooze what you have triaged. Once you have looked at an issue and decided it does not need immediate action, snooze it. A 7-day snooze keeps it off your dashboard without losing the history. If the issue resolves, you never hear about it again. If it is still there when the snooze expires, it resurfaces for another look.

Step 5: Set up alerts for the rest. If a store keeps having recurring issues, set up an alert rule so you get notified when it happens again without needing to check the dashboard manually.

When to Wait vs When to Investigate

The hardest part of issue triage is knowing when to act. Here are practical guidelines:

Wait when:

• The issue is "blocked" or "challenge" severity. These are almost always temporary.
• The fail count is under three. Transient issues self-resolve more often than not.
• You have seen this issue before on this store and it resolved last time.
• The store loads fine when you check it manually.

Investigate when:

• The fail count is above five and climbing. Something persistent is happening.
• A store that was reliably scannable suddenly goes to "down" status. A change happened.
• Multiple stores from the same platform show issues simultaneously. This could be a platform-wide problem.
• A "DNS / TLS Error" persists for more than 24 hours. Domain or certificate issues are real problems, not transient noise.
• A "Not Found" error appears on a store you have been monitoring for months. The URL may have changed.

Act when:

• A competitor's store is genuinely down and you want to document the outage for competitive intelligence.
• The monitoring URL needs updating because the store restructured.
• You need to adjust your monitoring setup because a store permanently changed its traffic policies.

Using Snooze Effectively

The snooze feature exists because not every issue needs to stay on your dashboard. But sloppy snoozing creates blind spots. A few guidelines:

Snooze access restrictions aggressively. Blocked and challenge issues are the highest-volume, lowest-urgency category. Snooze them for 7 days. If they are still happening when the snooze expires, snooze again. You are not ignoring the issue. You are acknowledging that it does not affect the store's actual operations.

Do not snooze genuine "down" issues without checking first. A "down" store might be having a real outage. Spend 30 seconds verifying before you snooze.

Review your snoozed count periodically. Your weekly report shows how many issues were auto-snoozed. If the snoozed count is consistently high for a specific store, that store might need its monitoring settings adjusted or might not be worth monitoring at the current scan frequency.

Issues, Anomalies, and Alerts Working Together

These three systems cover different ground, and they work best as a team:

Issues tell you about monitoring health. Is the scan working? Can Bonesaw reach the store? Are there access problems?

Anomalies tell you about unusual business activity. Did a store's pricing behavior change? Did the catalog shift unexpectedly? Is something statistically out of the ordinary?

Alerts notify you proactively about events you defined as important. A price dropped below a threshold. A new product appeared. A store went down.

A healthy monitoring setup uses all three. Issues keep your monitoring infrastructure honest. Anomalies catch patterns you did not think to watch for. Alerts notify you about the specific events you care about most. If you are only using one of these, you are leaving gaps.

Common Operator Mistakes

Treating every issue as urgent. Most issues are transient. If you react to every yellow badge, you will spend all your time investigating things that resolve on their own. Use the severity and fail count to prioritize.

Ignoring issues entirely. The opposite mistake. If you never look at the Issues Center, you will not notice when a competitor's store genuinely goes down, when your monitoring coverage degrades, or when a URL change means you are monitoring a 404 page instead of a product catalog.

Confusing "blocked" with "down." A blocked store is a working store that is filtering your monitoring traffic. A down store is a store that might be having real problems. The operational response is completely different.

Not checking the store manually. Bonesaw tells you what it sees from its vantage point. When an issue is ambiguous, spend 10 seconds loading the store in your browser. That single check often resolves the ambiguity instantly.

Over-monitoring stores that consistently block. If a store blocks your monitoring every scan and you snooze it every week, consider whether that store is worth monitoring at the current frequency. Reducing scan frequency can sometimes resolve persistent blocking while still giving you useful data.

Frequently Asked Questions

What does "stale" mean on a store? A store is considered stale when its last successful check was more than 24 hours ago. This does not necessarily mean something is wrong. It might mean the scan has not run yet for this cycle, or a transient issue delayed the scan. If a store stays stale for more than 48 hours, check the Issues Center for active problems.

Should I remove a store that keeps showing issues? Not usually. Issues are informational. A store that is blocked still provides value when the block lifts and scanning resumes. Only remove a store if you genuinely no longer need to monitor it.

How do issues relate to my weekly report? Your weekly report includes an issues summary showing total issues by type and auto-snoozed counts. This gives you a weekly checkpoint without needing to check the Issues Center daily.

Why does the same store show different issue types on different days? Infrastructure is not static. A store might timeout on Monday (their server was busy), return a challenge page on Wednesday (their WAF rotated policies), and scan fine on Friday. Intermittent, varying issues are normal for stores with aggressive traffic management.

When should I set up an alert for store health issues? If a specific competitor's availability is strategically important to you, configure a site-down alert so you are notified when the store goes genuinely unreachable. For most monitoring, the weekly report summary is sufficient.

---

Bonesaw is a product of MoonsLink. Monitoring capabilities described in this guide reflect publicly accessible product data collected through standard web protocols. Bonesaw does not access private or authenticated data. All data collection respects robots.txt directives and site access policies.