{
"vendor": "Pinpoint",
"slug": "pinpoint",
"platform": "statuspage",
"status_url": "https://status.pinpoint.support",
"last_checked": "2026-09-16T12:28:20Z",
"last_state": "ok",
"history_backfilled": true,
"first_watched": "2026-09-04T07:06:16Z",
"incidents": [
{
"body": "## **Email delivery disruption - 29 August to 1 September 2026**\n\n**What happened**\n\nBetween Saturday 29 August and the afternoon of Monday 31 August, and again from 23:30 BST on Monday 31 August until 11:09 BST on Tuesday 1 September, emails sent from Pinpoint were not delivered. This affected candidate communications, notifications and other outbound email across the platform.\n\n**Cause**\n\nBoth disruptions were caused by our email delivery provider, Postmark. An account restriction was applied on their side and, following its resolution, a required manual review by their team was not completed. This left the restriction in place and caused their systems to accept our emails as sent while not delivering them. No errors were returned to us, which is why the second disruption was not detected until customers reported it.\n\nPostmark has confirmed the fault was theirs, apologised, and made changes to their review process and our account settings to prevent a recurrence. No changes to Pinpoint contributed to the incident.\n\n**Resolution**\n\nOn Tuesday morning our engineering team identified that the issue was upstream and restored delivery by routing all email through a new sending channel with Postmark. Delivery was confirmed working by 11:09 BST.\n\nAll emails affected during the disruption have since been delivered. A small number of recipients may have received duplicate copies of some emails as a result of the recovery; we apologise for any confusion this caused.\n\n**What we're doing**\n\n* We have added the ability to switch email delivery channels immediately via configuration, so a similar provider-side issue can be worked around in minutes rather than hours.\n* We have expanded the notifications we receive from our provider so that account issues are visible to a wider group of our team, including out of hours.\n* We are adding monitoring on delivery volume so that a drop in delivered email is detected by us, independently of whether our provider reports an error.\n* We have formally raised the handling of this incident with Postmark and are reviewing our email delivery arrangements more broadly.\n\nWe're sorry for the disruption this caused you and your candidates. If you have any questions or have identified any specific emails you believe were not delivered, please contact your Customer Success Manager or [support@pinpointhq.com](mailto:support@pinpointhq.com).",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-09-01T15:01:59.355Z",
"resolved_inferred": false,
"started_at": "2026-09-01T08:20:01.581Z",
"state": "postmortem",
"title": "Emails stuck in sending status",
"updated_at": "2026-09-02T11:13:05.752Z",
"url": "https://stspg.io/dscz9ln4v3ll"
},
{
"body": "Support Update \u2013 Resolved\n\nFin (formerly Intercom) has deployed a fix, and the issue now appears to be resolved. Our team once again has access to the support inbox and is responding to your queries.\n\nWe'll continue to monitor the situation closely in case anything changes. Thank you for your patience while this issue was being resolved.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-03T16:42:56.309Z",
"resolved_inferred": false,
"started_at": "2026-08-03T14:33:16.449Z",
"state": "resolved",
"title": "Support Update",
"updated_at": "2026-08-03T16:42:56.326Z",
"url": "https://stspg.io/mnfvkf850d52"
},
{
"body": "This incident has been resolved.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-06T00:30:36.212Z",
"resolved_inferred": false,
"started_at": "2026-06-05T12:33:25.942Z",
"state": "resolved",
"title": "LinkedIn Integration \u2013 Delays in RSC Data Sync",
"updated_at": "2026-06-06T00:30:36.226Z",
"url": "https://stspg.io/p2r4vrl2t1lk"
},
{
"body": "**Duration:** Approximately 4 hours of intermittent disruption \\(03:00 \u2013 06:51 UTC\\), with two distinct impact windows.\n\n## What Happened\n\nPinpoint experienced an unexpected service disruption in the early hours of 13 May. The incident had two impact windows: an initial period of unavailability between approximately 03:00 and 04:00 UTC, and a follow-on period between approximately 05:39 and 06:51 UTC during which users attempting to modify certain types of records \\(predominantly scorecard submissions\\) encountered errors.\n\nNo data was lost or corrupted, and no background jobs were delayed.\n\n## Timeline \\(UTC\\)\n\n* 03:00  \n  Initial impact begins; application unavailable.\n* 04:00  \n  Initial impact resolves; engineering team investigating.\n* 05:39  \n  Second impact window begins; errors on a subset of record updates.\n* 06:29  \n  Status page warning posted.\n* 06:51  \n  Second impact window resolves.\n* 07:04  \n  Incident marked as resolved.\n\n## Why It Happened\n\nThe disruption was caused by an unexpected interaction between a routine internal database operation and an active background process. This combination of events is an outlier we had not previously encountered or anticipated. The root cause has been fully investigated and is understood.\n\n## What We're Doing About It\n\n* **Additional Monitoring**  \n  We have put additional monitoring in place to detect this specific class of interaction much earlier, before it can cause customer impact.\n* **Increased Database Capacity**  \n  We have provisioned additional database capacity to further reduce the likelihood of recurrence.\n\n_We sincerely apologise for the disruption and appreciate your patience._",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "critical",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-13T07:04:33.671Z",
"resolved_inferred": false,
"started_at": "2026-05-13T06:29:14.000Z",
"state": "postmortem",
"title": "Production Service Disruption \u2014 Database Storage",
"updated_at": "2026-05-13T14:51:42.146Z",
"url": "https://stspg.io/rx4v89wk1yjp"
},
{
"body": "**Date:** 19 March 2026\n\n**Duration:** Approximately 35 minutes \\(11:46 to 12:21 UTC\\).\n\n### What Happened\n\nPinpoint experienced a service outage beginning at approximately 11:46 UTC on 19 March. Users were unable to access the platform and received 503 errors. Full service was restored by approximately 12:21 UTC. No data was lost or corrupted.\n\n### Timeline \\(UTC\\)\n\n* **11:46** - Automated monitoring alerts triggered for service unavailability.\n* **11:47** - Engineering team began investigating.\n* **12:01** - Status page updated to reflect the incident.\n* **12:10** - Root cause identified as a database firewall misconfiguration introduced during an infrastructure change.\n* **12:20** - Fix applied; service restored.\n* **12:21** - Incident marked as resolved.\n\n### Why It Happened\n\nDuring an infrastructure configuration change, a database firewall rule was inadvertently applied with an overly restrictive scope. This prevented our application servers from connecting to the primary database, causing all requests to fail.\n\n### What We're Doing About It\n\n* **Immediate fix:** The firewall configuration has been corrected and verified.\n* **Hardening:** We are making production database firewall rules explicitly immutable and tightening API token permissions to prevent unexpected firewall modifications.\n\nWe sincerely apologise for the disruption and appreciate your patience.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-03-19T12:21:23.372Z",
"resolved_inferred": false,
"started_at": "2026-03-19T12:01:17.301Z",
"state": "postmortem",
"title": "Investigating Service Disruption",
"updated_at": "2026-03-19T13:38:43.581Z",
"url": "https://stspg.io/d4tp152gn1rl"
},
{
"body": "> What happened\nUsers were unable to preview CVs and cover letters within the platform. The preview area appeared blank or showed a \"blocked by browser\" message. Downloading resumes continued to work normally throughout.\n\n> What caused it\nA security update was deployed overnight to protect admins from potentially harmful files. While the protection worked as intended, it had an unintended side effect - it also prevented the resume preview from loading correctly in all browsers.\n\n> What we did\nIdentified the cause within minutes of being alerted\nDeployed a fix to restore normal resume previewing\n\n> What's next\nWe have applied an alternative security protection using a different approach that doesn't affect the preview.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-03-18T10:02:00.360Z",
"resolved_inferred": false,
"started_at": "2026-03-18T08:22:01.003Z",
"state": "resolved",
"title": "Resume Preview - Viewing Issue",
"updated_at": "2026-03-18T10:02:00.376Z",
"url": "https://stspg.io/dl47vjylqcbn"
},
{
"body": "Component: Pinpoint \u2192 Partial Outage\n\nInvestigating - 05:00 UTC:\n> We are aware that some users may be unable to perform actions that involve saving or updating data. Our engineering team is actively investigating.\n\nIdentified - 06:45 UTC:\n> The auto-scaling configured on our primary database infrastructure failed to provision additional storage in response to increased load. As a result, the database entered read-only mode, preventing write operations. We are provisioning additional storage to restore full functionality.\n\nMonitoring - 06:57 UTC:\n> Additional storage has been provisioned and write operations have been restored. Our team is monitoring to confirm full stability across all services.\n\nResolved - 07:01 UTC:\n> The issue has been fully resolved and all services are operating normally. We apologise for the disruption and are reviewing our auto-scaling configuration to prevent recurrence.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-03-03T05:00:00.000Z",
"resolved_inferred": false,
"started_at": "2026-03-03T05:00:00.000Z",
"state": "resolved",
"title": "Service Degradation - Database Write Operations Unavailable",
"updated_at": "2026-03-03T11:46:23.934Z",
"url": "https://stspg.io/zc5d9yr2gr32"
},
{
"body": "**Date:** 12 February 2026\n\n**Duration:** Approximately 30 minutes \\(14:00 - 14:35 UTC\\), with a brief secondary disruption during recovery.\n\n### What Happened\n\nPinpoint experienced a service outage beginning at approximately 14:00 UTC on 12 February. Most users were unable to access the platform and received 504 timeout errors, though partial capacity meant some requests were still being served. Full service was restored by approximately 14:35 UTC.\n\nSome outbound emails were delayed due to background workers also being affected. All queued emails were delivered by approximately 16:15 UTC. No data was lost or corrupted.\n\n### Timeline \\(UTC\\)\n\n* **14:00** - Automated monitoring alerts triggered for service unavailability.\n* **14:02** - Engineering team began investigating.\n* **14:08** - Root cause identified as a network configuration conflict introduced by a third-party infrastructure provider.\n* **14:20** - Initial fix applied; service stabilising.\n* **14:22** - Third-party provider's automation reinstated the conflicting configuration, causing a brief secondary disruption.\n* **14:30** - Fix reapplied with additional safeguards to prevent recurrence.\n* **14:35** - Full service restored.\n* **16:15** - All delayed outbound emails delivered.\n\n### Why It Happened\n\nA third-party infrastructure provider applied an automated network configuration change to our servers. The change was overly broad and conflicted with our own networking configuration, causing the majority of inbound traffic to be dropped. During initial recovery, the provider's automation re-applied the conflicting change before we implemented stronger protections.\n\n### What We're Doing About It\n\n* **Immediate Safeguards:** Protections are in place to prevent this specific change from affecting our infrastructure again.\n* **Removing the Dependency:** We are accelerating work to bring the affected networking functionality fully in-house, removing the third-party dependency entirely.\n\nWe sincerely apologise for the disruption and appreciate your patience.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-02-12T15:02:21.310Z",
"resolved_inferred": false,
"started_at": "2026-02-12T14:05:09.069Z",
"state": "postmortem",
"title": "Service Unavailability",
"updated_at": "2026-02-13T10:56:50.316Z",
"url": "https://stspg.io/kqmcwmmbbfgj"
},
{
"body": "We have identified the missing records within the platform and restored the affected data.\n\nIf you have any questions or require assistance please reach out to our support team via the in-app chat function",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-11-30T19:30:00.929Z",
"resolved_inferred": false,
"started_at": "2025-11-28T12:03:37.000Z",
"state": "resolved",
"title": "Investigating Missing Records",
"updated_at": "2025-11-30T19:30:00.946Z",
"url": "https://stspg.io/wx06hn0zfngz"
},
{
"body": "This incident has been resolved.\n\n> What happened\nFollowing a planned infrastructure update last night, some customers experienced errors when performing certain actions on the platform, particularly around candidate pages and interview scheduling. We identified the root cause and restored full service by reverting to our previous database infrastructure.\n\n> Current status\nThe platform is now fully operational. All features are working normally.\n\n> Data impact\nDue to an issue between both database providers when we restored service, there's a short window (between 10:16 and 10:57 UTC this morning) where some changes made on the platform may not yet be reflected. No data has been lost, we have complete records of everything that happened during this window and are working to restore any affected changes to the live system.\n\nThe status of data reconciliation is being tracked here: https://status.pinpoint.support/incidents/9v65gddb3y1n\n\n> A note on our recovery standards\nWe maintain internal Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) as part of our commitment to platform reliability. The 41-minute data gap from this incident falls outside the standards we set for ourselves, and we take that seriously. While no data was lost, we're treating this as a priority learning for our infrastructure processes going forward, and feedback for our vendors and their practices. \n\nA full post-mortem will follow on Monday.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-11-28T11:31:48.000Z",
"resolved_inferred": false,
"started_at": "2025-11-28T10:33:30.000Z",
"state": "resolved",
"title": "Investigating Service Disruption",
"updated_at": "2025-11-28T17:56:35.015Z",
"url": "https://stspg.io/5d0kg5svnzmc"
}
]
}