Status
Measured by the service itself and read straight from its own request log. Nothing on this page is a promise — it is what actually happened. Refresh for the current numbers, or read /status.json.
Operational
| Database | reachable |
|---|---|
| Renders in flight | 0 active, 0 queued |
| This instance has been up | 1h 22m (since 2026-08-25 13:26 UTC) |
PDFMint runs as a single service. A deploy restarts it, which resets the uptime figure above — it measures this process, not the service's history.
Last 24 hours
| Documents produced | 710 |
|---|---|
| Succeeded | 704 |
| Refused before rendering | 1 — a bad option, a page that answered 4xx, a selector that never appeared. The credit is refunded. |
| Failures on our side | 5 |
| Success rate, excluding refused requests | 99.29% |
| Success rate, counting everything | 99.15% |
| Render time, median | 119 ms |
| Render time, 95th percentile | 513 ms |
| Render time, slowest | 1,133 ms |
Bars count failures on our side only, not requests we refused. One bar per hour over the last 24 hours, tallest bar = 273 documents. Red means at least one document failed in that hour. Hover a bar for the exact count.
Last 7 days
| Documents produced | 2,563 |
|---|---|
| Refused before rendering | 21 |
| Failures on our side | 30 |
| Success rate, excluding refused requests | 98.82% |
What we do not have
Being straight about it, because you are about to depend on this:
- No third-party uptime monitor yet. The numbers above are self-reported, and they count only this deployment — a development machine sharing the database used to show up here.
- No SLA, and no SOC 2 report.
- One instance, one region (Frankfurt). A deploy causes a short restart.
- Render failures refund the credit automatically, so a bad minute does not cost you documents.
If something is broken, open an issue at github.com/fstandhartinger/pdfmint/issues.