OneWebDesk
All toolsGuides
한국어|English

Ops / SRE

SLA, cron, timezones and capacity planning.

The Ops / SRE toolkit is a set of calculators for anyone who has to turn service reliability and cost into hard numbers. Use it to see how many minutes of monthly or yearly downtime an SLA actually allows (99.9% vs 99.99%), what an hour of outage costs in lost revenue, when a cron expression next fires, what an epoch or ISO timestamp in your logs maps to in your timezone, how much bandwidth cost and server RAM a traffic spike requires, and what latency percentiles like p95 and p99 really mean. It is built for SREs, backend and infrastructure engineers, DevOps practitioners, and ops staff writing incident reports or doing capacity planning.

The common workflow for these checks is straightforward. Start from a target SLA or a measured value (availability, response time, traffic), then translate it into a concrete operational figure: allowed downtime, monthly cost, or required resources. During incident response and postmortems, convert log timestamps so your timeline lines up, validate the next cron run so scheduled jobs aren't silently missed, and read percentiles to understand tail latency and whether an SLO was breached. Every calculation runs entirely in your browser and no input is ever sent to a server.

Uptime SLA Calculator
Compute allowed downtime per period for 99%–99.999% SLAs.
Cron Next Run Calculator
Show the next run times for a cron expression.
Log Timestamp Converter
Convert epoch/ISO timestamps to KST, UTC and local time.
Bandwidth Cost Calculator
Estimate monthly bandwidth/CDN cost from traffic and unit price.
Downtime Cost Calculator
Estimate the cost of an outage from hourly revenue, conversion rate and downtime duration.
Server RAM Calculator
Estimate the RAM a web server needs from concurrency, worker count and per-process memory.

Frequently asked questions

What's the difference between SLA, SLO, and SLI?
An SLI is the metric you actually measure (e.g., 99.95% availability, 200ms p99 latency), an SLO is the internal target you set for that metric, and an SLA is the external, contractual promise to customers that carries penalties if breached. Teams usually set the SLO tighter than the SLA to leave headroom. The downtime calculator turns any availability SLA into the exact minutes of downtime it allows.
Why look at percentiles like p95 and p99 instead of the average?
Average response time hides a small number of very slow requests (tail latency), so it understates what users actually feel. p95 means 95% of requests are faster than that value, and p99 marks the slowest 1% where complaints usually originate. SLOs are typically defined against p95 or p99 rather than the mean.
My log timestamps are in epoch numbers or UTC and it's confusing.
Server logs are usually written in UTC or Unix epoch (seconds or milliseconds), so you need to convert them to your local timezone to line up an incident timeline. Paste the value into the timestamp converter and it returns a human-readable time in whatever timezone you choose.
Can I rely on these calculator results directly?
They're reliable as fast, formula-based estimates, but real cost and capacity planning involves many variables. RAM depends on your workload and caching strategy, and bandwidth cost depends on your cloud provider's pricing tiers and free allowances. Use these figures as a starting point for sizing and decisions, then refine them with your actual monitoring data.
🌐 Network / IP📡 DNS / Domain🔒 TLS / Certificates✉️ Email🛡️ Web Security⚡ HTTP / API🔍 SEO / Indexing🚀 Performance / Frontend📝 WordPress / CMS☁️ CDN / Cloud💰 AdSense / Monetization