# Page Size Monitoring & Defacement Defense | Uptimeify > A 200 OK doesn't mean healthy. Monitor HTML payload size per endpoint and catch empty renders, code bloat & defacements early. Start your free trial. Source: https://uptimeify.io/monitoring/website-monitoring/page-size-check A status code only tells you the server answered, not that the right page shipped. Monitor HTML payload size per endpoint and catch partial renders, injected code and bloated releases before your client spots the regression. Start Free Trial Measure HTML Payload for Free ## Page Size Monitoring. A 200 OK Proves Nothing. For the technical stakeholder ### Byte Measurement & Baseline Logic: How It's Wired This is how it is wired. Read the Page Size Check documentation https://docs.uptimeify.io/monitoring/monitoring-types/page-size Source raw HTML body measured in bytes on every check. Metric Content size is recorded per run, independent of the response status code. Baseline An expected byte corridor is established per endpoint for comparison. Scope Measures the HTML document the server returns, before client-side assets load. Payload Layer ## Byte Count Doesn't. The Status Code Lies. The A page can answer a clean 200 and still be broken: half-rendered, missing a content block, or quietly failing in the backend. Page Size Check measures what actually leaves the server: the real size of the response body. That gives you a structural signal for whether the HTML you shipped still matches the page your client expects. - **HTML payload in bytes**, so you stop leaning on the status code as your only health signal and start reading the substance of the response. - **Structural drift detection**, so you catch missing content blocks, broken templates and silent failures before they turn into a ticket. - **Per-endpoint baseline**, so every critical page in your portfolio carries its own expected byte corridor instead of one blanket rule. For the technical stakeholder ### Threshold Evaluation & Run Logic: How It's Wired This is how it is wired. Read the Page Size Check documentation https://docs.uptimeify.io/monitoring/monitoring-types/page-size Min too small blank states, partial renders, template failures. Max too large code bloat, injected snippets, runaway embeds. Corridor The monitor fails only when the payload leaves your chosen byte range. Evaluation Each run is judged against the corridor live, no historical graph needed. Threshold Layer ## Two Guards. Min and Max. One Corridor, Too small and too large are different failures. You set clear lower and upper bounds for critical landing pages, logins or checkout routes. Uptimeify checks every run against that corridor and flags anomalies on the spot, with no historical graph data to store. - **Min threshold**, so you catch empty states, partial renders and template failures the moment a page drops below its normal size. - **Max threshold**, so abnormal payload growth from unoptimized assets, injected snippets or runaway embeds never slips past you. - **Limit corridor**, so the monitor only fires when the payload truly falls outside your bounds, not on every harmless fluctuation. For the technical stakeholder ### Size Spikes & Integrity Signal: How It's Wired This is how it is wired. Read the Page Size Check documentation https://docs.uptimeify.io/monitoring/monitoring-types/page-size Defacement Sudden payload spikes often accompany injected malware or unauthorized scripts. Empty render A drop below the normal footprint flags content blocks that failed to render. Performance Bloat that would hurt Core Web Vitals and crawl efficiency is caught early. Signal A size anomaly opens an incident before it ever becomes client-facing. Integrity Layer ## You Catch Both at the Size. Defacement and Bloat. Page Size Check defends integrity and performance at once. You catch defacements, broken render paths and bloated releases by their byte signature, before they become a visible incident your client reports first. - **Defacement defense**, so you capture suspicious payload spikes that often ride in with malware, spam links or unauthorized scripts. - **Empty-render protection**, so you catch pages dropping below their normal size when content blocks fail to render, even though the server answers fine. - **Performance ceiling**, so accidental code bloat doesn't quietly wreck your Core Web Vitals, crawl efficiency and user experience. ### SLA & Contract Templates Service Level Agreement templates to define professional boundaries with your clients. ### Pricing Calculator Find the sweet spot for your care plans. Calculate margins based on check frequency and support hours. ### White-Label Pitch Decks Powerpoint Templates that explain 24/7 monitoring to non-technical clients. Close more retainers. ### Churn-Proof Reporting Guide Use automated reports to proactively communicate value, so clients never ask what they're paying for. Claim your Success Kit and start scaling today. Claim your Success Kit & Start Monitoring Ready to turn monitoring into a profit center? Every Uptimeify subscription includes access to our Success Kit, a collection of battle-tested resources to turn your monitoring into a profit center. ## We don't just monitor. We help you sell. → For the technical stakeholder ### Byte Measurement & Threshold Logic: How It's Wired We use the response's `Content-Length` header when it's present, and fall back to counting the actually received body bytes when the header is absent (for example under chunked transfer or dynamic rendering). The value is checked against a min/max interval defined per endpoint: below "too small", above "too large", in between valid. The size check toggles independently via `checkSizeEnabled` and runs as part of the combined check alongside status, SSL and response time. A corridor breach flips the status regardless of the HTTP code. What does Page Size Check actually measure? The real size of the HTTP response body in bytes, how much HTML your page actually ships per request. That gives you a structural integrity signal beyond the status code: a page can return 200 OK and still be half-rendered or bloated, and the byte measurement is what makes that visible. Why isn't a 200 status code enough as a health signal? A 200 only confirms the server answered, not that the right page arrived. When a content block goes missing, a template aborts or someone injects foreign code, the status code often stays green anyway. The payload size shifts in all of these cases, so you catch structural defects through the bytes that the status code waves through. How do you set min and max bounds for a page? You define a byte corridor with a lower and upper bound per endpoint. The lower bound catches empty states and partial renders; the upper bound catches abnormal growth from bloat or injections. Every run is checked against that corridor. The monitor only fires when the size falls outside your defined bounds, so you don't get false alarms on harmless fluctuations. Does Page Size Check help against defacement and injected code? Yes. Unauthorized scripts, spam links or foreign embeds grow the payload measurably, often before the tampering shows visually. A size spike above your upper bound fires immediately, so you catch a compromise at the byte signal instead of when a client reports the defaced page. Does Uptimeify store historical size trends for this? No. The check is stateless: every run is evaluated against your fixed byte corridor, not a rolling historical graph. You don't need to retain size time series. The corridor alone delivers the verdict \"within limit\ or \"outside it\". FAQ ## Frequently Asked Questions Set a byte corridor per critical page and let Uptimeify check every run against your bounds. Empty renders, bloat and defacements get flagged before they become an incident, under your brand. ## Ready to See Broken Releases Before Your Client Does?