99.5% monthly uptime, automatic credit if we miss.

TenderPulse commits to 99.5% monthly uptime for the production customer-facing application — measured at the CloudFront edge, calendar-month aligned, and excluding the carve-outs in §4 below. 99.5% over 30 days corresponds to a maximum of approximately 3 hours 36 minutes of permitted downtime per month.

If we fail to meet the target in any calendar month, we apply a service credit to your next invoice automatically. You do not need to open a support ticket, attach screenshots, or escalate. We are operating the same status page you are watching, and our billing system reads from the same data source. The credit appears in your account within 5 business days of the end of the affected month.

We measure availability with synthetic probes hitting four critical paths every 60 seconds from independent geographic vantage points (Asia-Pacific, Mumbai, Frankfurt):

• GET /api/health — overall system liveness
• POST /api/auth/sign-in — authentication path
• POST /api/tenders/upload — primary product workflow
• POST /api/copilot/inference — AI inference path

A path is considered down when two consecutive probes fail. Downtime starts at the first failed probe and ends at the first subsequent successful probe. Downtime is calculated per path, then weighted by traffic to produce the monthly composite number.

The probe data is published in real time at our public status page (linked in §6 below) and is the binding source of truth for SLA calculation. We do not adjust the data after the fact.

Credits are calculated as a percentage of the recurring fee for the affected service tier. Credits do not stack across months — if we miss the target two months in a row, you get the higher credit each month, not a cumulative penalty.

The following are excluded from downtime calculation:

• Planned maintenance announced at least 7 days in advance via in-app banner, email, and the status page, scheduled outside Bangladesh business hours (after 9 PM Asia/ Dhaka or weekends), and capped at 2 hours per occurrence.
• Customer-caused outages — for example, misconfigured webhooks, exceeding documented rate limits, or using the API in a way clearly contrary to its specification.
• Force majeure as defined in our Terms of Service — natural disasters, government action, war, large- scale internet routing failures upstream of our cloud provider, and similar events.
• Issues caused by third parties outside our control — for example, a regional ISP outage in Bangladesh that prevents customers from reaching the internet, or a Bangladesh Bank-side outage that prevents EPS payment processing.

Our standard maintenance window is Saturday 22:00 – 23:30 Asia/Dhaka. We perform schema migrations, dependency upgrades, and infrastructure updates inside this window where feasible. Most maintenance does not require any service interruption — we deploy zero-downtime by default.

For maintenance that does require a brief interruption (under 5 minutes), we announce the window 7 days in advance via in-app banner, email to the billing contact, and the status page. The announcement describes what is being changed, why, and the expected impact.

For emergency maintenance (security patch, critical-CVE response), we deploy as fast as the issue requires and retroactively post an incident note explaining the urgency. The 7-day rule does not apply to genuine emergencies.

The TenderPulse public status page lives at status.tenderpulse.com.bd. The page publishes synthetic-probe data in real time, lists every active incident with severity classification, and shows historical uptime calculation for the prior 12 months. The page is hosted on infrastructure independent of our main application stack so it remains available during major outages.

For each incident we publish an initial notice (within 15 minutes of detection if the impact is customer-facing), regular updates every 30 minutes during the incident, a resolution notice, and a public post-mortem within 5 business days of resolution. The post-mortem describes what happened, the root cause, what we did, and what we are changing to prevent recurrence.

Customers can subscribe to status-page email or RSS for notifications. We also push critical incidents to the in-app notification banner.

Support response time SLAs by tier (response time, not resolution time — resolution depends on the issue):

• Free trial / Growth tier — 1 Bangladesh business day (Sun–Thu 09:00–18:00 Asia/Dhaka)
• Scale tier — 4 business hours (Sun–Thu 09:00–21:00 Asia/Dhaka)
• Enterprise tier — 1 hour, 24×7, with named support contact

For all tiers, security incidents reported via help@tenderpulse.com.bdget a 72-hour acknowledgement floor regardless of the customer’s plan, per our vulnerability disclosure policy.

You may terminate your subscription at any time from the billing settings page or by emailing help@tenderpulse.com.bd. Termination is effective at the end of the current billing period; we do not pro-rate by default but may at our discretion when termination is triggered by an SLA breach.

On termination, customer data enters a 30-day grace window during which you can: download a complete export in JSON + machine-readable formats (your account, company profile, tender history, AI bid drafts, audit log entries pertaining to your tenant), and reactivate the account by paying for a new period. After the 30-day window, customer data is deleted from primary systems within 30 days and from backups during the next backup cycle (typically within 60 days). GDPR Art. 17