How to prepare your status page for SaaS acquisition due diligence
A buyer opens your data room and asks for twelve months of uptime proof. You have a green dashboard screenshot and a status page that only shows the last thirty days. That gap kills trust faster than a single P1 outage. Status page due diligence for SaaS acquisition means packaging honest incident history, subscriber comms, and uptime exports before the LOI.
Quick answer
Buyers want 12 months of uptime data, P1 incident logs with recovery times, and post-incident write-ups — not marketing uptime claims. Export CSV uptime history, PDF incident posts, and sample subscriber notifications. Disclose gaps honestly instead of scrubbing old incidents. StillOnline gives micro-SaaS founders a lightweight public timeline plus external checks as evidence of operational maturity.
For why public status pages build B2B trust day to day, read our B2B status page trust guide. For security questionnaires buyers send alongside DD, see status page security questionnaire tips.
1. What buyers look for in uptime and incident history
Technical buyers ask the same reliability questions whether you run on Datadog or a simple uptime monitor. They want evidence, not vibes.
| Artifact | Typical ask | Why it matters |
|---|---|---|
| 12-month uptime | CSV or dashboard export from monitoring | Validates SLA claims and churn risk |
| P1 incident log | Count, duration, customer impact | Shows operational maturity |
| Post-incident summaries | Root cause + corrective actions | Proves you learn from failures |
| On-call proof | Who answered at 3 AM | Revenue stops when nobody responds |
| Subscriber comms | Email or status page notification samples | Tests transparency under stress |
| SLA credits | Paid credits in last 12 months | Signals repeated breaches |
Do: align status page incident titles with internal ticket IDs in a private appendix. Do not: rename incidents to sound minor — buyers cross-check timestamps with support tickets.
2. Export incident timelines and subscriber comms
Start exports thirty to sixty days before you expect serious buyer calls, not the week the data room opens.
- Pull uptime history — export monthly uptime percentages for twelve months from StillOnline, Datadog, or your monitor. Include probe URL and interval metadata.
- Archive status page incidents — save each incident post as PDF or HTML with timestamps, affected components, and resolution time.
- Capture subscriber notifications — export redacted email or Telegram alert samples from the last three incidents.
- Add maintenance windows — list scheduled maintenance with customer notice lead time.
- Bundle a README — one page explaining data sources, timezone (UTC), and any monitoring gaps.
Suggested data room folder: /reliability/uptime-12mo.csv, /reliability/incidents/, /reliability/notifications/, /reliability/README.md.
Do: use UTC timestamps everywhere. Do not: mix screenshots without raw exports — buyers ask for CSV anyway.
3. Honest gaps vs observability theater
Observability theater means pretty dashboards that go green while customers cannot log in. Buyers spot it quickly.
| Honest signal | Theater red flag |
|---|---|
| Incident post within 24h of P1 | Status page silent during known outage |
| Disclosed 6-month monitoring gap + fix date | Deleted incidents before DD |
| 503 on readiness when DB down | /health returns 200 while app unusable |
| Repeat incident with new runbook entry | Same root cause three times, no change |
Do: write a one-paragraph "known limitations" memo (solo on-call, no multi-region). Do not: claim 99.99% uptime without exported math.
If you only have six months of StillOnline monitoring, say so and show the start date of current tooling.
4. StillOnline as evidence of operational maturity
StillOnline is hosted uptime monitoring with an auto-created public status page. For micro-SaaS it replaces a heavy observability stack during DD prep.
- Create a project at stillonline.tech/app with your production health or app URL.
- Keep the public status page live through the sale process — do not hide incidents mid-negotiation.
- Export check history monthly into your reliability folder.
- Post incidents on the status page when probes fail, matching internal timeline.
- Enable alerts on Free (one channel) or Pro ($9/mo) for faster response proof.
Do: treat StillOnline as external synthetic proof — it hits the same HTTPS URL customers use. Do not: present status page uptime as application APM.
5. Parent checklist before the data room
- Twelve-month uptime export from monitoring (or cover letter if shorter history).
- P1/P2 incident register with start, end, impact, and postmortem link.
- Status page incident archive matching internal IDs.
- Subscriber notification samples (redacted).
- On-call roster or solo-founder schedule with escalation path.
- Deploy rollback runbook referenced in last incident post.
- SLA document plus credits paid table.
- Known gaps memo (monitoring start date, missing multi-region).
- Health check URL doc showing what external probes test.
- Quarterly review note showing incident trends and fixes shipped.
Do: rehearse a thirty-minute walkthrough with a friendly advisor. Do not: freeze the status page during active incidents to "look stable."
What's next
Package reliability evidence now so DD is a file upload, not a fire drill. Keep posting honestly on your status page, export monthly, and link the public timeline in your buyer FAQ.
Start a StillOnline project today if you lack external uptime history. Open the dashboard and paste your production URL.
Related guides
- B2B SaaS status page trust
- Status page security questionnaire for B2B
- Public status page for SaaS
- Post-mortem template for SaaS status page
FAQ
How far back do buyers expect incident history from StillOnline?
Plan for twelve months of uptime data and P1 logs. If you have less, export everything available and disclose the monitoring start date in your README.
Public vs private status page during M&A with StillOnline?
Keep the public page honest and accurate. Add a private folder with exports and redacted notifications for the data room.
What if I only monitored uptime in StillOnline for six months?
Ship what you have, explain the gap, and show the fix date. Buyers prefer honest partial history over missing files.
Should I delete old incidents from StillOnline before a sale?
No. Scrubbing looks like fraud. Archive with context instead.
Can StillOnline history replace Datadog for acquisition DD?
For micro-SaaS external uptime and a public timeline, yes as primary evidence. Enterprise buyers may still ask for APM or log samples.
Do buyers care about StillOnline status page design?
They care about post-incident write-ups, notification speed, and whether incidents match support tickets. Design is secondary.
What files belong in the reliability folder with StillOnline exports?
CSV uptime, incident PDFs, notification samples, on-call roster, SLA credits table, and a one-page README describing sources and timezones.