Notes from Getting on the Hacker News Front Page

Status: Observed L1 (Level 1) Peak Baseline | Event: Hacker News Front Page Exposure | Observation Screenshot Date: 2026-07-29 (KST)

I want to record the operational baseline observed from actual public traffic this time. Given the nature of my site, which mostly covers programming-related topics, visitor counts tend to be low. Average daily visitors are around 600–900, and the daily average for June 2026 was approximately 637.

Going forward, I intend to treat the maximum inflow observed from Hacker News front-page exposure to date as the L1 Peak for the current service.

Deployment boundaries at the time

Browser
  -> Cloudflare (DNS, WAF, edge cache)
  -> Vercel / Next.js (public Web & Web BFF)
  -> Cloudflare api.makonea.com
  -> 4 GB Lightsail (Nginx, BFF, content/assets/RAG, PostgreSQL)

The Cloudflare Zone-wide metrics may include web requests handled by Vercel, requests intentionally bypassed such as RSC and prefetch, and api.makonea.com requests. Therefore, Cloudflare's "uncached" count should not be treated entirely as requests reaching the Lightsail origin.

Observed Values

UI Display Values for Reference Only

The values below are not used for capacity calculations because the selected range and display unit on the screen do not match.

The Cloudflare screen's selected range is Previous 24 hours, but the maximum and minimum values on the unique visitor graph are displayed in Per week units. Therefore, 17.42k and 690 should not be interpreted as hourly visitors, instantaneous concurrent users, or a clearly defined 24-hour aggregation bucket. Both values are preserved solely as reference UI display values from the screenshot and are excluded from capacity assessments and derived metric calculations.

The Cloudflare screen's selector is set to Previous 24 hours, but the horizontal axis and the maximum/minimum units on the unique visitor graph are displayed as Per week.

The total requests on the maximum request bucket screen show 132.15k, which does not match the 444.46k from the Zone-wide screen. Differences in hostname, filters, bot inclusion, analytics product, or query window may account for this discrepancy, so the two values should not be combined as if they represent the same population.

Because of this discrepancy, 17.42k is not reinterpreted as hourly visitors or instantaneous concurrent users, and the exact peak RPS and concurrent user count could not be determined from this data alone.

Derived Metrics

Large-byte responses such as static assets were largely absorbed by the edge. The request-count cache hit ratio being lower than the bandwidth-based ratio appears consistent with a mix of small but intentionally uncached requests, such as RSC, prefetch, API, and auth/admin paths.

The exact cause appears to be Unknown until a breakdown by hostname, path, cache status, and content type is performed.

On Capacity Assessment

Conclusion

The current configuration is assessed as having withstood a short-term inflow at the scale of this L1 Peak.

During this event, the observable Cloudflare edge transport layer and the Lightsail CPU layer showed no explicit saturation signals while handling the L1-HN inflow.

Basis:

• The 10-minute average CPU peak of 17.57% remained within Lightsail's sustainable 20% zone.

• CPU burst remaining stayed at 100%, meaning no short-term CPU emergency headroom was consumed.

• Approximately 77% of total data transfer was handled by the Cloudflare cache.

• This observed data contains no signals of CPU saturation or burst credit exhaustion.

That said, the worst-case CPU point is only 2.43 percentage points below the sustainable threshold. This result therefore serves as evidence that no explicit saturation was seen in the Cloudflare edge and Lightsail CPU layers during an inflow of this scale, but it is not evidence that the same state would hold over a long period at twice the traffic volume. End-to-end service quality and repeatability still require additional verification of error rates, latency, memory, and database metrics. If traffic doubles and sustains, the system could enter the burst zone, so a separate load test or evidence from the next real-traffic event is needed.

That would probably require being on the Hacker News front page for an entire day; based on current data, the exposure lasted approximately 6 hours.

Metrics to Collect Without Fail at the Next Peak

The following metrics were not available this time.

• 4xx and 5xx error rates per Cloudflare, Vercel, and Lightsail

• p50, p95, and p99 response times for public HTML and API endpoints

• Lightsail memory, swap, disk I/O, and container restart/OOM counts

• PostgreSQL connection pool wait times and slow queries

• Cache miss request distribution by hostname, path, cache status, and content type

• Peak RPS and concurrent request count at 1-minute or finer intervals

At the next Hacker News-scale inflow, at minimum all of the following conditions should be met together to consider the L1 Peak successfully passed again.

The 5xx and latency thresholds are not values observed in this screenshot; they are operational alerts for evaluating the next peak. Once actual data accumulates, these thresholds should be adjusted to match the observed distribution.

Conclusion

The Hacker News front-page exposure was a rare real-world load event gained through running a personal site, and honestly it felt great.

After experiencing an incident in the past where an AWS billing error showed an abnormal charge of roughly 30 million KRW, I migrated to a Lightsail-centered setup where costs are easier to predict. The 2 GB instance lacked sufficient memory and operational headroom, but the current instance showed no clear saturation signals in CPU or burst capacity during this HN traffic event.

Within the current observation scope, I therefore consider the setup to have achieved operational stability worth the cost. That said, instance costs and specifications need to be re-confirmed against the AWS billing statement, and at the next peak I plan to collect not only CPU data but also error rates, latency, memory, and PostgreSQL metrics.

Hands-on experience with infrastructure load is hard to come by, and I am recording it here for that reason.